Why developer relations programmes fail

Speaker 1: So this talk is the talk I get myself in trouble with. The first thing I want to throw out is a disclaimer, and that is I work in developer relations and marketing. So I run developer relations and marketing at MuleSoft, but I'm going to pick up marketing a lot today because it's fun to do. More importantly though, I really feel blessed that I consider myself a developer, really getting to do what I love doing, is being part of the community and trying to give back and repay people for giving so many great things to me. The last time I gave this talk, I had a guy come back to us, he goes, Well, why are you talking about Devopulations?

Speaker 1: Blah, blah. So here's my very quick resume. This will be I've started two Devopulations programs, the first being Constant Contact, where we quadrupled sign ups in the first six months. And then I've been really blessed to be at MuleSoft where we've grown the community about 400,000 developers. So with that said, developer relations is a pretty big buzzword right now, right?

Speaker 1: People are like, no, we don't care. We just want a break. By the way, just a heads up, I always told people I'm really excited for the breaks. I'm only going an hour and a half. Is that good?

Speaker 1: Yes. In fact, companies will launch them left and right, and we all know developers are now called the new kingmakers. Woo hoo. I stole that from a book. It was amazing.

Speaker 1: But the sad reality is that most developer relations programs are going to fail to meet their potential, and a lot of them are just going to downright fail. And we look at that from a marketing side or a developer relations side, the sad thing is it's not because of metrics. I want you to think about that for a second. Why is it that developed relations programs fail even if the metrics aren't the cause? The first reason developed relations programs fail is developed relations is hard work.

Speaker 1: It's all about creating trust within the community, but also creating trust within your company. How many people here get into developer relations? How many people work with marketing? How many people work with sales? Many people like working with both?

Speaker 1: See, the fun thing is marketing and sales, though, are really the two most powerful departments within your organization usually. They're the ones that make the money for the company and pay our paycheck. So as you think about it, it takes time to build trust not just with the community, but also with your own teams. And of course, developer relations is far more than just blogging or going to events. And the ROI is slow.

Speaker 1: It's really tough because we say, going to this event. It's going be great. And then we're like, how do we justify the fact that we just spent $10,000 at a sponsor event and talk to these developers? Once you've established trust, we all know this, developers are some of the hardest working, most loyal advocates you'll ever have. And I think that's one of the key things is we're not just trying to say, Let's go make a sale.

Speaker 1: We're not just trying to say, Let's get developers to use our platforms. We're saying, Let's get developers to go share this technology with others. Let's get them to go to these conferences and talk about it. Let's get them to go sing the praises of this great technology. So when you think about developed relations, it's a lot like marinating a steak.

Speaker 1: I don't know, it's the best thing I could think of. Number two reason that developed relations programs fail though is not having a unified vision. Everyone wants a developed relations program for different reasons. If you go to MuleSoft and you pick on our execs, you ask our execs what they want from developer relations, you'll ask 11 different executives, and you'll get 11 different answers. You can't please everyone, but you need to understand who are the key stakeholders.

Speaker 1: We need to make sure that our CTO is happy, that marketing is happy, that our CEO is happy. Again, don't even try to please everybody, but also keep your program focused. One of the challenges is we say, Oh, we're going to do this, this, this, this. Pretty soon we're doing 15 things, and we're not doing one or two things well. It also means making sure your company is setting you up for success and the architecture is setting yourself up for success.

Speaker 1: For example, if you're managing an organization, whether it's marketing or CTO or biz dev, you report to them and DevRel and DevMarketing report to them, fantastic. That's super easy, makes everything pretty simple to do. By the way, which department should developer relations be reporting to? Relations. Development relations.

Speaker 1: But it's gonna report to somebody. It would be the CEO, the CTO. CMO. Found Should be or Should be. Should be.

Speaker 1: I found the answer is whoever is the most invested in your program. Whoever wants to see you succeed. A lot of organizations say, Look, have developer marketing, developer relations, and we'll have them report to the same people so that overall they have the same goals, same KPIs. That can work pretty well. One of the dangers though is when you run into, Well, we have marketing and marketing is going to handle our developer marketing and the CTO is going handle developer relations.

Speaker 1: Once you find yourself getting split in two different groups with two different stakeholders, that starts to create some challenges. Some of the challenges is that pretty soon teams have different overall goals. Marketing's here going, Hey, let's get developers in the pipeline. And the CTO may say, Hey, this is great. Let's have a cool name for our company or a cool perspective.

Speaker 1: Lack of communication understanding. Teams end up working against each other if you're not careful. Developer community interest is not always a priority. If it's from the marketing side and they're focused on revenue, they may not say, Oh, how do developers perceive us? What's the trust like?

Speaker 1: Let me see how do we get them in as a lead and convert them. And again, this isn't just a people problem, it's not just who you're working with, it's because you have different goals, different ideals, and eventually, if it's not remedied, it's gonna be palpable externally. People are gonna know things are not well within the company. If you find yourself set up that way, the first thing you do is make sure you get meetings set up. Make sure you're syncing with the other person.

Speaker 1: Make sure you have your own internal communication. Make sure that you're talking and that your goals and the way you measure those goals mesh. And again, keep the line of communication open. This is really hard, especially for companies where you have DevRel and marketing. Make sure you work with marketing on a regular basis.

Speaker 1: And then have a single source of truth for conflicts, because there will be conflicts. Who's gonna be the decision maker? Who's gonna say, Hey, I'm sorry, but marketing gets this one? Or, Hey, you know, I kind of like this idea, let's try that. But again, be proactive in solving issues before they arise.

Speaker 1: Otherwise, they're going to come back and they're going cause a lot of damage. Number three. By the way, this goes just like this, all number threes. Not understanding developed relations. How many people here are like, Yes, I know everything about developed relations, and I've got it?

Speaker 1: Alright. That makes me feel better. It doesn't feel really bad for this slide. It's still really new and a lot of us are struggling with what is developed relations. Not just us, but companies.

Speaker 1: I think we all know that developed relations is not tech support, yet there are companies who shall remain unnamed that hire evangelists and all they do is tech support. It's not talent and recruitment. It's not sales. It's not traditional marketing. It's all of the above.

Speaker 1: Developing relations is developing relations. So that also means we can't focus on short term ROI, but rather, again, the meat of the program is long term. If we think of that steak, we can either say, Let's just throw it on the grill really quick and get out there and we'll have food. And if you have my steak, it's really burnt and charred up and no good. Or you can marinate it, let it sit, then have a delicious steak.

Speaker 1: I'm making myself hungry. This is not good. Number four: taking resources for granted. We all know this. Developer relations is really, really, really hard work.

Speaker 1: How many people here are evangelists? Okay, I'm getting myself in trouble with the evangelists here. If you're in the field, developer evangelists work on average of sixty to eighty hours a week. People agree, disagree? More or less?

Speaker 1: I'm hearing more. In fact, at Constant Contact, I hit the one hundred hour mark several times. That's why I became a manager, which is a horrible joke to say managers don't work. I tried. But as we think about this, when we think about developer evangelists, the average lifespan of developer evangelists is nine to twelve months.

Speaker 1: This is important for everybody who's in evangelism. Your lifespan is nine to twelve months. If you've been doing it longer, you're unique. Travel. Travel is a lot of fun.

Speaker 1: I'm excited to be here in London. This is actually my first trip out in North America. It's super awesome. I'm learning all these new words in English. I actually stopped at the airport and tried to interpret a sign and then realized it was English.

Speaker 1: But when I was at Constant Contact in October one year, I got to spend three days at home. The rest of time I was on the road. Now I want you to think about this, evangelists consider this as well. It takes about six months to a year to on ramp as evangelists, to actually understand what you're out there talking about and be representing your company, and yet in nine to twelve months, most evangelists burn out. You need to make sure that that's not going to happen to you.

Speaker 1: And if you're hiring evangelists, you also have to remember that these are the people representing your company. So watch out for signs of burnout. Like to say evangelists are like racehorses. They'll run hard, but they'll run themselves to death. And as an evangelist, if you're not careful, you will do that to yourself.

Speaker 1: If you have multiple evangelists, separate rotational schedule. Get them time to work on blogs, get them time to work on software, to write code, a really novel idea. Give them some time at home starting on the road all the time. If you're managing evangelists, make them take time off. How many evangelists voluntarily take time off and actually disconnect from your phone, your computer, etc?

Speaker 1: See, I saw a whole bunch of hands go, we're like, Yeah, we take time off. And it's like, Actually, when I worked at Constant Contact, I would go to bed around midnight, 01:00, wake up at 06:30, check my email. When I left Constant Contact, I took a month off. I went in withdrawals for two weeks to try and figure out what to do. Picked my phone like, I have no new emails.

Speaker 1: There's no Slack messages. What do I do? You should ask how many people would survive two weeks without Internet. Have a funny story about that. I'll share it later.

Speaker 1: Number five. This is tough, especially when we're in marketing, valuing leads over relationships. I got myself in trouble because there's a reason we call it developer relations at MuleSoft and not developer marketing. We do both, but we're focused on the relationship. Leads are people you want to do something.

Speaker 1: You have an objective and you want them to do that objective for you. Relationships are people who want to do things for you. That's the big difference. And this is one of the challenges that we have, and sometimes this gets lost in translation. Leads are really, really easy.

Speaker 1: You go to an event, you scan a badge, you've got a lead. Fantastic. They have an instant ROI. You can send a quick email, maybe 1% will open the email, another 1% will sign up. Boom, there's our ROI, we got it.

Speaker 1: Relationships are hard, but they're like diesel engines. At MuleSoft I don't know, stole that from somewhere. They keep going. At MuleSoft, we have our Champions program. We get the people in the program, and they don't just say, Yes, I want to use MuleSoft's platform.

Speaker 1: It's awesome. These are people writing books about MuleSoft. These are people writing blog posts. Last year they were about $2,000,000 worth of content. If marketing decided to do it, would it cost us $2,000,000 to do it?

Speaker 1: Also keep in mind that developers, of course, are sales and marketing averse. And I think that there's two different types of marketing, by the way. Because we hear this in developer relations saying marketing is a bad thing. It's not a bad thing. There's aggressive marketing which is you see the guy with the can of Coke, he goes, I got Coca Cola, Coca Cola, it's so delicious.

Speaker 1: You want Coke? Yes, you want this Coke. You need to get this Coke. This is the best thing ever. You'll never taste anything better at all.

Speaker 1: Coke Gold is a customer, so have to do that. Then you go to the movie theater, you sit down, and you're watching the movie, and they say, Please turn off your phone as a guy drinks a cup of Coke. And you're like, Dang it, I forgot my Coke. You go back and get it. There's a difference in aggressive and passive marketing.

Speaker 1: And you want be careful in trying to sell developers and being too pushy because one the things about developers is they're very, very loyal again. But we can also be a little bit opinionated, a little bit volatile sometimes. And if you tick us off as loyal as we are, we might just go to the competitor and say, Hey, let me help you. Developers also have a particular set of skills. And that's great, but what they want is they want be recognized and valued for those skills.

Speaker 1: How many people here want to go to work every day and go, Nobody knows I'm here. As an evangelist, we probably do it like, Please, no meetings. We want to know what people care about us and think about us. And like that stick, the ROI comes off in the end, and it's far tastier than if we throw it in the pan. So what we can do, again, don't try to sell our market developers.

Speaker 1: Instead, engage them and find out where they stand and what they like or don't like about your company. Listen to all feedback. When I started with Constant Contact, one of the challenges we had is we're seeing this old, archaic, boring company. And I went to a meetup in Wisconsin and bought the developers a few rounds. And by the way, if you want honest feedback, a few rounds will do that.

Speaker 1: And for three hours I listened to them say not one positive thing about the company. Not one positive thing. And we listened feedback and said, Okay, we'll try to work on this, we'll try to change this. A month later, we actually received a recommendation from that user group where they said, Yep, they're working on fixing those things by the way they listen. Even though we hadn't changed anything yet, even though we still had things we had to prove on, they knew that we listened and we cared.

Speaker 1: Let them know their feedback is valued and that the work they do is valued. Recognize the people in your community, whether you have a list of developers or on your forums give them badges, and keep them involved. Another challenge we have is an inability to segment markets. I like to say you can give a dog a bath, but you probably shouldn't get a cat a bath. That's my cat picture, I know.

Speaker 1: I actually wanted to get a picture of my cat, giving the cat a bath, but that turned out very horribly and I ended up in the ER that day. In other words, what works for one person or one group may not work for the other. And that means that as you look at other developed relations programs, understand what works for them may not always work for you. Understand your community. Understand who you're trying to reach and what they like about your product and what makes them want to be excited about your product.

Speaker 1: Also understand that unless developers are your primary customers, your current marketing probably isn't going to work. So you need to find a new way in messaging and tone to really reach them. So again, forgive about marketing developers. And by marketing, forget about being aggressive about it. Go tell them the story.

Speaker 1: Tell them why you're excited about the technology. Find time to understand the developers that are using your technology and your service already. By the way, if you're trying to grow a community, if you're trying to build out a new community, at MuleSoft, we started growing out our community by talking to our developers in Buenos Aires and talking to a few developers that use us here and there. And we let them lead the charge for us. Lean on them to help you develop your developer messaging and build the community because they know your community the best.

Speaker 1: They know your messaging. They're already telling their friends about how great you are. And then work to empower those in marketing creative to better understand your developers and utilize that message. Again, we like to say, we're not evil, don't do marketing. Work with your marketing teams.

Speaker 1: Work with your sales teams. I'm not saying bring your sales guys to your booth to have them talk to the developers, which we do at MuleSoft, woohoo, But you want to have a strong relationship with them. And of course, I think this gets lost sometimes as people from the outside look at developers. Developers are very, very social, and we love community. And by letting them become leaders and building the community, again, we're telling them that they have a value.

Speaker 1: They're the reason our community exists. If you look at MuleSoft, we talk about our Champions program, it's not Mike Stowe's program. It's not MuleSoft's program. It's our community that really makes the program what it is. Quick disclaimer: cats really do not like baths.

Speaker 1: Just throwing out there. Number seven: marketing and trying to market. Marketing is based on people and emotion. If you think about it, want to get people excited. How many people have ever talked to a depressed marketer?

Speaker 1: No, they're always like, let me tell you how great a is. Tell Let you what's new. Let me tell you what's exciting. How many people ever talked to a developer who's like, let me tell you what's new. Let me tell you what's exciting about our company.

Speaker 1: A couple of people. Okay. So you get a cross branch there. Developers tend to think more logically. We look at, Okay, if this, then that.

Speaker 1: If that, then this. It gets me in trouble all the time. Another way to think of it is if we look at the insights discovery. If we look at energies, people tend to communicate differently. Typically you find developers within the blue red zone.

Speaker 1: So they tend to be a little more cautious, little more precise, deliberate, maybe a little bit questioned. How many developers here have ever questioned someone's product? Just a few. Okay. They also tend to be a little more demanding, determined, strong willed, purposeful.

Speaker 1: On the flip side, marketers tend to fall in the green and yellow categories. So they are more sociable, dynamic, persuasive, enthusiastic, caring, encouraging, sharing, patient, and relaxed. I know, we always have trouble with stereotypes here. When we did this whole thing, ironically, was the only engineer on my team at ten to have any green. And I was weird because I had green and red, which really means show me you care and then get out.

Speaker 1: But again, you tend to see that people talk differently, they communicate differently. And this is a key part of our jobs, is we talk to developers. We understand developers communicate differently. Sometimes we forget that marketing communicates differently, and we need to cross that spectrum. Again, we want to be careful because there's this instinct that says we have to have a good product and we need to sell the product.

Speaker 1: We're out here to tell you how great the product is. One of the best times I had was a guy at the company who goes, You know, this part of your product sucks. I looked at him and said, Yeah, it does. He's like, What? No, I agree.

Speaker 1: We had a great conversation, and again the next week he started going, You've to talk to these guys because this part of their product sucks, but the rest of it is amazing. And I think it's been said 15,000 times: Integrity, integrity, integrity. That's what developers probably value the most. I think on the DevRel survey, one of the results was empathy. I think those are the top two right there: integrity and empathy.

Speaker 1: So do again, stop yourself from marketing. Don't go out there and tell them how great the product is. I got myself in trouble with marketing at Constant Contact, if you can't tell, by the way. And we went to an event and we sponsored with a booth. And I was at the booth and a person came up and I was like, Hey, how was the event?

Speaker 1: And we started talking about the sessions. The next guy came up and goes, Hey, how was that session you went to? We started talking. Hey, what are doing with PHP? And I had one guy come up and goes, So tell me what Constant Contact does.

Speaker 1: We're a small business market, but how was the event? And my market person was standing there going, You didn't tell a single person about Constant Contact or what we did. And I said, Just wait. And what we'd see is during the hallway track, people would come back and say, Tell me about Constant Contact. Because chances are when they come up there to get the swag and stuff, they're not super interested in your company at that moment.

Speaker 1: They're just saying, What do I have to listen to to get your swag? Whereas if you establish that relationship with them, if you find that common interest, now they want to have that conversation. So be honest, be concise, be yourself, and then get involved and invest in the community. Also, non tech marketers usually have a stereotyped opinion of developers. I think sometimes developers get opinions of developers.

Speaker 1: And as I show this, by way, pick on the marketing people about the stereotypes, remember that we as developers have the same stereotypes about marketing, sales, CEOs. So, we could say all developers like computers. They like TVs and movies, video games, RPGs, talking about nonsense, happy hours. The reality is that some developers like these things. You know, I have a friend who worked with me at a social network company.

Speaker 1: He absolutely hates social networks. Of course, some developers like cars, sports, politics, social events, outdoor activities, etc, etc. Picking up marketers, I like to say, Hey, which one of these guys is the developer? And they usually say, This guy or that guy. The truth is, of course, they're all developers.

Speaker 1: And then, so are these. By the way, that's me in the yellow shirt dorky way down there. But here's a hackathon. This is Hackfit from a couple of years ago, where you've a bunch of developers doing aerobics and dancing and everything else, and here's a notepad because we like technology. And this is important too because we think about developers, they have families.

Speaker 1: They like technology, they think differently, they push boundaries, but we start falling into false segments. And the first is we start thinking about who our competitors are. Our competitors are not the companies that compete against us. Our competitors are things like Netflix, Google, Facebook, spending time with their kids. Why should developers invest in your company and learn your technologies and your skills versus those things?

Speaker 1: What's the return that they're going get? And how is it going to better provide them to take care of their families and be successful? We also look at developers and say, are they an enterprise developer or are they a small business developer? The truth is they're a developer. They may be working in a small business, may be working in enterprise, but that's their occupation.

Speaker 1: That's where they work. The second they leave, they could be a different type of developer. So understand who your developers are, and don't get lost in necessarily the segmentation of saying, Do we target enterprise developers, non enterprise developers? If they're writing code, they're a developer. Again, they also spend a lot of time in front of a computer staring at code.

Speaker 1: And I think we all know this already. Code is probably the most exhausting thing. It's like writing a book nonstop or reading essay after essay. So find ways to provide mental stimulation without making them think in-depth. The more ways you can engage them in fun approaches both offline and online, the better.

Speaker 1: Again, they like challenges. They're often very opinionated. If you can't tell I'm going go over by trade. Up here, I'm very opinionated. Be aware that you may have to adjust.

Speaker 1: Some people will be introverted, people will be extroverted. And also keep in mind that their choice for creating will, but there's also very deliberate and purposeful and then sometimes accidental exclusion for companies in the developer world. If you're just starting developer relations, if you're going with developer relations, don't expect your company to be received right off the bat. Don't expect developers to start welcoming you, especially if your company has had a reputation in the past. Again, trust has to be earned.

Speaker 1: And developers are very good at trying to keep people out of things. How many here go to a meetup? A couple of people. How many people love having recruiters at meetups? A couple of people.

Speaker 1: Now does that mean that we don't want recruiters? Absolutely not. We want them talking about the jobs. We want to know what opportunities are available to us. But we do start to create these communities where it's exclusive to us.

Speaker 1: And that really means you can't really market to developers unless you're taking part in their world. It doesn't mean you have to be technical. It helps. If you're technical, you have two things right off the bat you can talk about. You can talk about technology and your company.

Speaker 1: They're interested in your company. So treat developers as individuals, Be prepared to engage with them in honest, intellectual conversations. Show them you care. Again, sometimes that best sales pitch is not trying to sell something. It's showing them that, Hey, we want to work with you.

Speaker 1: One of the most unfortunate events I saw at an event was we had a guy who bought a booth to support the developer conference. He said a sales guy, and a sales guy literally tried to sell to every single developer that walked by. He'd really walk up be like, Hey, hey, let me talk to you. All right. Let me talk about our product, how great it is.

Speaker 1: Fantastic? No, you don't want to listen, Hey, let me tell how great our product is. And she's like, No. And he couldn't understand why developers wouldn't engage with them. And at the end of the conference he said, This was a waste of money.

Speaker 1: Which doesn't help out either. But find a way to engage with them without selling them, build that relationship. And again, work to be an active part of the community, not just at events, not just places like this, but offline, online, hosting meetups, going to meetups, helping with open source projects. Value the relationship with the developers over the leads. Number eight thing that kills developer relations programs: lack of creativity.

Speaker 1: We love creativity. Because creativity is what we do. We create things, we build things, we invent things. And when you're creative, it shows that you care enough to do something really special for us. You're not just saying, Here's a charger, here's a yoyo.

Speaker 1: You're doing something special for us. And that's one of our best marketing tools. How many believe that creativity is one of your best marketing tools? A couple of people. How many people have seen this?

Speaker 1: Lisa, the Octocat. That's the thing. With Creative, immediately people go on, GitHub. And creativity doesn't have to be expensive. Anybody know the story of Lisa the Octocat?

Speaker 1: A couple of people? GitHub found Lisa on iStock Photo for their four zero four page. That's how this started, a cheap purchase on iStock Photo, which has become really the icon of GitHub. It doesn't have to be expensive, it just has to be creative and fun. Or if you want to get yourself in trouble, to a Ruby conference, have your mascot ride in a Yak from Ninefold eating the Ruby logo.

Speaker 1: Works really well. It's the little things that count. And swag is often the first impression people have of your company. How many will hear go to a booth just for the swag? A few people?

Speaker 1: Okay. How many people are still awake? Couple more? Okay, some people. Alright.

Speaker 1: How many people like audience participation? Never gets all okay. And again, it doesn't have to be expensive, but it should be high quality, shouldn't be super cheap and memorable. With Constant Contact, we found these things, they're called wobblers. They come in four different colors and expressions.

Speaker 1: And I remember buying these, and my marketing team nearly killed me. And we took them there, and we had developers who would grab one and say, Oh, this guy is so awesome. They'd throw it in a wobble. We had developers who would find the red one and say, Yeah, this is how I feel right now. Going put this on my desk.

Speaker 1: You know, so have fun things, create engagement. For Sunshine PHP, we had a Sunshine yo yo thingy. With MuleSoft, we have our little Maximumel mascot squishy thingies. We also created comic books. But one of the best pieces of swag I've ever seen is something called the Flatball.

Speaker 1: This is also from Sunshine PHP. And I went there, and all they had were these little blue Frisbees sitting on their booth. How many people are excited to get a Frisbee? Yes, thank you. But they had a video, and the video is one of those classic TV sales videos where it says, Do you have trouble catching the ball?

Speaker 1: Do you wish it could float in air longer? We have created and engineered the new ball just for you, flat ball. And people were going, is so awesome. It's something memorable. It's something that you don't forget about.

Speaker 1: So again, understand your current perception in the community. Do or how do developers perceive your company as it is? With Constant Contact, we're a little bit archaic. With MuleSoft, we were cool, but we went from open source to enterprise and we kind of neglected some developers in the process. What's the perception people have of your company, and how can you either reverse or encourage that perception?

Speaker 1: Make it relatable to your company and users. Think outside the box. The little USB chargers are awesome. I have 50 of them. I think I have 60 yo yos.

Speaker 1: I'm not allowed to get swag at events anymore. Be creative. And empower your developers. What are you giving them, and what does it say to them? Again, three reasons I stopped by the booth: I know someone there, I want to say hi.

Speaker 1: I know the company or use the company, which means I'm already excited about them. Or I see something cool. Otherwise, I do this. Do you want to talk? Food Food wise.

Speaker 1: Depends on the food. But all three have me have a real conversation. I talk to these companies. Again, creativity is one of your best marketing tools. Almost done here.

Speaker 1: Professionalism gaps. When talking to developers, please do not be too formal. That means if you show up at a talks to an event, actually you'll probably get a lot people talking to you, but we want to try to avoid that. When talking to developers, you don't want to be too informal. Unless you're in San Francisco, in which case it's okay.

Speaker 1: This isn't being recorded, is it? So know your audience. Biz casual usually works pretty well. Jeans and a t shirt depends on the event. I went to one conference where I came in the first day I was wearing a t shirt and jeans.

Speaker 1: Everybody else was in suits. I was like, Crap. So I run home, next day I get my suit coat, come in, everybody's wearing t shirts and jeans. Sometimes you can't win. But create an image.

Speaker 1: As an evangelist, create an image. Who are they going know you as? How are they going know you as? Be professional, but also fun. And this is really important because I think sometimes we lose this.

Speaker 1: You can do both. If you look at MuleSoft, this is just a handful of our customers right here. Large enterprises, companies are serious. They don't mess around. Yet if you look at how we engage our developers there, how we work with our developers, we have a comic book.

Speaker 1: We have the Max the Mule mascot jumping out and scaring the crap out of me during a live session. We have what's the history of MuleSoft on our website. We have challenges for our champions that say, Do not do this challenge. Ironically, most popular challenge we have. And of course, take your program seriously because it is really, really hard work.

Speaker 1: Honestly, those are more often than not the reasons programs fail. With that, if you're like, hey, this is cool, but I want learn more about building developer portals, etcetera, etcetera, or more about API design, we have an awesome meetup tomorrow. That's my sales pitch for that. Otherwise, you can find more on Devopulations at mikestowe.com. And if you're like, wow, this was amazing, I am blown away by how awesome this guy is, please shoot a tweet to DevRel or MuleDev and say, this is awesome.

Speaker 1: If you hated a talk, please see me afterwards. I give out bribes. Thank you.