Made by
Made by
April 18, 2018
Events and Marketing Coordinator at Hoopy
Want to tell your employer about the amazing things Dev Rel can do? Need to explain to them what it simply can’t? Then use some tips from Crate’s Jessica Rose who may (or may not) also know ways to avoid fighting on the internet. From DevRelCon Tokyo 2017.
Yeah. Hello. So, I’m going to talk to you today about what developer relations is fantastic for and what it’s not very good for and I’m going to give you ways to argue with your boss. Hopefully, very, very well. So, the first thing I’m going to warn is that this is, sort of, a 101 level talk. It’s a beginner level talk. So, who here is working in developer relations now? Cool. Who here is working in developer relations a little bit? Cool. And who here wants to go into developer relations or their company is thinking about it? Cool.
To give you a little bit of introduction about myself, my name is Jessica Rose and I’m an American living in England, but before that, I lived in Osaka for a long time. So, I speak very, very bad Japanese and I’m going to try not speak Japanese for the camera, so that I can pretend my Japanese is good. So folks listening at home, my Japanese is excellent. So, please come up and ask me questions afterwards. I’m also very, very lazy and because I’m very, very lazy, I’m going to ask that sometimes you yell at me. So, who here is very shy?. They’re like, “Cool, cool, you’ll be fine.” Whenever you see this symbol…
Man: Woah.
Jessica: Close, yeah. Whenever you see this symbol, yell at me. Tell me what I’ve forgotten and if you think I say something that’s wrong or something that’s silly, you should come fight me, but politely on the internet. There, and who here is a native speaker of English, English is your first language? Cool. If English is not your first language, it’s okay. If I say something too quickly or if I say something strange, go like this. Yeah, the people next to you, they’re not looking at you so it’s okay, but I’m going to be able to see you, it will be fantastic.
So, I’m going to tell you a story about someone in developer relations who is totally not me. Not me at all. Her name is Jennifer. So, Jennifer had a job that she started, and she loved it. She started this job in developer relations and Jennifer was doing really interesting things and Jennifer’s boss came to talk to her and say, “Hey, Jennifer,” because that’s her name, said, “We want to do a mass email campaign. We want a cold email, maybe 5,000 or 6,000 developers and please, put your name on the email.” And Jennifer said, “Oh, that might be a little difficult. I don’t think developers like it when you email them. Maybe if we could use someone else’s name, that would be fantastic.” And Jennifer’s boss said, “Oh, no, no. We’re going to do this, and it must be you. You have a lot of credibility. We’re going to use your name on this email.” Jennifer said, “Well, really, it’s not okay. I don’t want this to happen. You can’t use my email. You can’t use my name on this email. It’s not going to happen. No way.” And then Jennifer’s boss said, “Well, actually, the email went out this morning. So, it’s already happened. It’s okay, right?” And it was fine, completely fine. And because of this, my friend Jennifer suggested I write this talk.
So, the first thing we’re going to look at is a very, very common argument in developer relations. So, what is technical outreach? So, some people say, developer relations and some people say developer evangelism and some people say developer marketing. And for me, my opinion on this is very, very clear. I don’t care.
Woman: Yes.
Jessica: I think this is mostly the same thing. So, I’m going to talk to you about any kind of developer outreach, any kind of technical outreach and I think this is mostly okay. I say, “You know what? Developer outreach for this talk is any kind of peer supported.” So, it’s a technical person talking to technical people and trying to achieve goals. This is okay? Eh…no, no, just no.
The first thing we’re going to start very, very positive. What is technical outreach fantastic for? And for this, we’re going to be looking at goals not activities. So, hackathons, writing blog posts, all of these are activities, building demos. I just want to talk about big picture goals. Technical outreach is a fantastic way to drive awareness of your project or of your product. If people don’t know about you, they can’t use you. They can’t use your product. If people don’t know you, they can’t come work for you. So, the first thing a lot of people do, a first thing of goal for technical outreach is saying, “Hey, here’s who we are. Look at us. Look at us. We’re fantastic.”
Also, it’s really great for increasing adoption. Increasing adoption is a totally reasonable goal for developer outreach. It’s also wonderful for hiring. Once people know who you are and what they do, if you’re a nice person, of course they want to work with nice people. This is a fantastic way to get other nice people to come and work with you. Developer outreach and technical outreach is a fantastic way to get feedback. Of course, technical products will have issues raised on GitHub. They’ll have people emailing. They’ll have bug reports, but if you’re some place in person, the things people will tell you are much, much different. Every type of feedback, gets different kinds of information. Sometimes you’ll be working on something and somebody come, a hackathons, “Hey, hey, hey, this new feature, it’s terrible. Come here and let me show you why.” Being in field, whether on or offline, is a really, really good way to get further information.
Developer outreach is also fantastic to contribute to support. Who here whose working in developer relations does some support? Cool. I strongly believe that it’s a fantastic way to make sure your developer relations team has a lot of empathy for people working with your product and it’s also a really good way to make sure they stay very, very good on the product. It’s fantastic to build a community, to nurture a community. It’s like, well, we’ve got a product. We’ve got a project and we’ve got people aware of it. They know we’re here and we’ve got people using it, but now, let’s build a community. Let’s draw them together where they can talk about it, share tips and tricks and share information, but also, you may have a community that already exists. Having a dedicated technical outreach team means that you can grow and make more visible the people who are already doing great things in your community.
And this next one is a little bit tricky. Having an outreach team can be fantastic for very, very friendly investigations into what other companies are doing. You’re not a spy, but if you see a problem in your company, you said, “Well, we have this problem. We need to fix this.” If you have developer relations team members, they’re going out into the world and they’re talking to other companies. They’re talking to other users that could say, “Well, we have this problem. You know, Twilio, they did this to fix this problem. Shall we try that?” It’s a very, very way to be a friendly spy.
Another great goal with developer relations is you’ve got the opportunity to build developer education, technical education for new and potential users. People who aren’t using your tool at the moment, letting them know here’s what it’s good for, here’s how you use it, here are some use cases, here are some demos. Really, teaching newbies is a fantastic way to get involved. But also, lowering the barrier to entry for people who are already using your product and say, “Well, you know, I’ve been using this for a long time. I have these problems. Here are my pain points.” Technical outreach is a fantastic way to determine what those pain points are and start addressing them through technical education and my favorite one is relationship building.
Relationship building means you’ve got people going out into the world, online, offline. I think those are our only options, is VR, no, but they’re going and they’re building real human relationships. So, the top right before mine we saw a little tiny domino going forward and knocking over a hundred pounds of stone. You’ve really got opportunities to build real lasting relationships and those relationships have the ability to impact your future community, the future of your company, really big, beautiful, scary things. You can also support existing marketing and PR efforts. If you have a traditional marketing team or traditional public relations team, you can go ahead and support their message in the wild. So, here I’ve said it’s good for awareness, adoption, education, what have I missed?
Developer relations goals. You all are way too polite or English speakers, come on, I’ve not missed anything. You’re going to let me walk off here and say, I’ve list every single possible goal for developer relations and I’m done.
Woman: Selling for us.
Jessica: Selling for, let’s go, okay. We might have to like fight politely after this.
Man: Finding great stories.
Jessica: Oh, damn. That’s perfect, finding great stories. I was like to leave you, like, I’ve aced it and nobody can ever say I didn’t, finding great stories is fantastic. Anything else I’ve missed? I got all, but one. Good, good, good.
And this is something. I wanted to do this talk because this is a great time to show your boss just this part, cut off the part of the talk where I said, “Show this to your boss.” Here’s what technical outreach is not always fantastic for. I see a lot of companies trying to use developer outreach as field sales with really, really firm numbers. What did you sell this week? What did you do?
The difficult thing here is that if you’re working in developer outreach, you need to have very, very clear credibility to developers. If you’re, sort of, enterprise-style selling to developers, you’re going to have a very challenging time talking to them like a peer. As in the example, developer relations people should not be used for email or mass marketing. Who here really loves cold emails? If you have the option never use your developer relations team for cold emails. If possible, never use cold emails for developers. Everyone hates them. No one likes them. People will make fun of you on the internet. I will make fun of you on the internet nicely with hearts. And although your developer relations team can help you support public relations, never try and replace your PR team or never have the developer relations people stand in for a PR team.
Who in this room can write a really good press release? Okay, unless you hire a unicorn, like Karina, never, never have your developer relations team working as your PR team. A lot of times the way we phrase things and the way we interact with developers is not good for traditional press. If you’re in a startup environment, don’t set your DevRel team to be your investment team. They can build some really interesting relationships with investors. They can help you raise awareness. They can help you get adoption numbers, but they’re not always going to be the best people to go ahead and have you meet with investors. I’d warn as well that your developer relations team shouldn’t be contributing a large part of your core product. If they’re in charge of building the thing and promoting the thing, they’re going to have a difficult time deciding what they’re doing with their time. You can have your developer relations team nicely, suggest things they’ve heard from other companies. Don’t use them for espionage. So, if someone comes to me and says, “Jess, Jess, Jess,” you hang out with some of the Twilio team sometimes, I said, “Yes, I do.” Go find out what they’re doing in the next release. Well, I really like Phil.
Man: Oh, really? Does Phil know?
Jessica: And I know that working practices in Japan and in the west are often very different, but in the west turnover in developer relations are very quick. So, most people change jobs every two or three years. So, if you say, “Hey, go spy on that company.” Say, “No, I like them and sometimes they buy me beer, and maybe I’ll have to work for them someday.” No. Never, ever, ever send them out as spies. They’re not going to do a good job. Yes?
Man: And someday you might get acquired by them or something…
Jessica: Yeah, don’t ask them to make enemies for you and you know what’s happening, what did I miss? What else is developer relations bad for?
Woman: Selling products.
Jessica: Selling product? I’m sorry. Yell at me.
Man: Email.
Jessica: Email, yeah. In general, which I have them said, “No emails.”
Man: No, I send email.
Jessica: Oh, okay. It’s okay to send the emails. Like, cold emails?
Man: Not cold emails, warm emails.
Jessica: Warm, friendly, lovable emails. Not spam?
Man: Not spam.
Jessica: Cool. Is there anything else developer relations is terrible for?
Man: Shipping.
Jessica: Shipping. Like, physically or both?
Man: Product.
Jessica: Right. That’s it?
Man: Were you in the API?
Jessica: I’m not your mama.
Woman: DevOps.
Jessica: DevOps.
Man: Earlier, you mentioned support is good thing for developer advocate. I feel like they can have, they can facilitate, but they cannot be useful.
Jessica: I’ve seen that happen a lot of times. We’re like, “Hi, this is a small company. You’re going to be developer relations and work for product, and you’re going to do support, and also make tea.” And that rarely ends well.
Man: Is it with me everyone in the community is?
Jessica: Writing the laws of physics. So, all of these are just a list of good things to try and do and bad things. Things you shouldn’t try and do, but often times we don’t have as much control as we would like. What can you do when your boss comes to you with something ridiculous? When your boss comes and says, “Hi, I don’t really know what developer relation does, but please sell this to all the developers.”
So, I’m going to talk you through things you can do early in the beginning sort of prevention. Things you can do once there’s a problem and what you can do when the conflict is inescapable. And I understand that working practices in Japan and in the west are often very, very different. So, I’m going to try and go ahead, and make this accessible to both sides. I know saying things like, quit your job is not a very helpful advice in Japan.
So, please, let me know if any of this isn’t very good for the region we’re in. Before there’s a problem far, far in advance, if you have the opportunity when you’re looking for a new job, take your time and research. Look for companies who understand what you do and respect what you do. Pick places where they’re going to listen to you and they value you, and they respect you whenever possible. Maybe all the time, but definitely whenever possible.
When you can, work with managers and work for managers who have a track record of defending their team. If you’re looking for work in developer relations, it’s a fairly small community. Ask other people when you’re looking for work, what’s your manager like, what do they do, do you respect them, do they respect you? Taking your time, I’ve selected contracts and selected jobs based on, “I really think that manager is going to do well for me.”
Long before there’s a problem, make sure that your boss and their boss know about goals. Make sure that they’re educated about what developer relations is good for and what it’s not good for at all. If they come to you after six months and say, “Please, do cold emails,” maybe you’ve already failed by not letting them know what the goals are. And I’m so sorry for this, but you have to let your company, not just the developer relations team, but the larger company, understand what you’re doing and why.
Often, if your company doesn’t understand your job, it can be a good excuse to relax. You say, “Oh, I’m very busy doing things.” But if they don’t understand what you do, it makes it more difficult for them to give you tasks that are appropriate and measured. So, these are all prevention. These are all picking a good job, educating your teams, but what happens once there’s a problem, can someone give me an example of a problem with developer relations where you might be given something, a task you shouldn’t be doing?
Man: Support.
Jessica: Support, like, please be our support team?
Man: Yeah.
Jessica: Good. So that’s going to be our example. When someone comes to say, “Hello, you’re our developer relations person. Now, you’re also the support team.” A fantastic thing to do is revisit what the goals are. He said, “When I started at this company, these were our goals. We wrote them down. Being support by myself, it doesn’t really overlap with our goals. Do you want to change my role? Do you want to change the team, or do we want to go back to these original goals? We want to go back to our core mission.”
When someone gives you a task that’s inappropriate for developer relations, make sure you tell them why it’s inappropriate, both in person and in writing. So, make sure you say to them very, very politely, of course, they’re your boss. “Hi, I can’t be your support team because I have other tasks. It would keep me from interacting with the community. I don’t have enough time and I don’t have the skills to be full-time support.” But after you tell them, make sure you also send this in an email. This way if things go terrible later on, you have a record of you saying, “That’s a bad idea.” Ask your manager to support you. Your manager’s job is to make sure that you’re successful at your job. If there’s a problem and someone above them is saying, “Please, do this,” and it’s a terrible idea, ask your manager to fight for you.
Whenever you can, cite. That is the wrong cite. Whenever you can cite outside experts, outside materials. And say, “Do you know what? This is the bad idea.” Here’s an article about why it’s a bad idea. Here’s a conference talk about why it’s a bad idea. If you are on a similar time zone as me, please have your boss email me and I will tell them why it’s a bad idea, mostly politely.
So, going in to a job, you have a lot of options. Let’s say, here are things you can do in selecting a role. Here are things…oh, sorry. Does anybody have any other advice, ways to try and get around, being given an inappropriate task?
Man: Question.
Jessica: How can I help you, sir?
Man: How do you do with, like, more of the one off the place. He’s like, “Oh, we want you to come to this sales event, but it’s not going to be your main job or your business like.” You know, the questions just meant, the things you were just talking about there, kind of more and like, “Oh, we want to do to change the entire structure of what you’re doing, but what I’ve seen just tji week .” Oh, just for like this week, we would like you to suddenly be sales for this week because we have a big sales event coming and this has to happen…
Man: It’s a quick thing to say.
Man: It’s a quick thing. It’s not very much.
Jessica: It’s often a lie. It’s never a quick thing. So, it’s very similar advice. So, if someone comes to you and says, “Hi.” Oh, please.
Woman: I ask implication questions. So, if someone said to me, “Vanessa, I would like you to send this email to 5,000 developers,” I would say, “What do you think is going to happen after that? What it’s going to achieve? What is it going to achieve? How does that contribute to your long-term goal? Is that going to be like a six-month win or a two-year lose?” Like, that’s I ask people to get think through that her applications.
Jessica: Yeah, so, maybe?
Woman: Okay.
Jessica: The exact same thing for one off or for enduring things talk about revisit your goals, say, “You know what? You brought me in to do this job, not this job. If you ask me to do this for one week, here are the tasks that I won’t be able to do. Here are the reasons that asking me to do these things might be a silly idea,” and you probably don’t want to say silly. “And here are other options. Here are other ways to get things done.”
So, one offs, often the very same tactics. So, saying, here’s why this could be a problem. Here’s why I don’t want to do it. Here’s documentation around that. So, if you went and followed all of this advice, you’re a star. You spent a lot of time and research the next job you’re going to take. You’re working for a manager you think is going to be very, very careful in defending you. You’re working on a team where you’ve communicated what developer relations is good for and what developer relations shouldn’t do, and then you have a problem, and you’ve tried all of these things around the problem. You’ve tried to offer an alternative. You’ve tried to tell people why this is a bad idea. You’ve tried to cite outside sources. You’ve had them fight me in emails, but none of this works. You still have this problem and your boss says very firmly and say, “You know what? We are going to send out this email to 5,000 people and it will have your name on it and everyone will hate you.”
What can you do about that? Does anybody have any advice for that before I go? What do you do when your boss says, “This must happen,” and nothing you do is changing it?
Woman: Send the next email with their name on it.
Woman: I think, I mean going to direct questions of what happened to prompt said email. So, if they’re going to do it anyway. I think, you know, bringing that and saying, “You did this and I recommended not to and here’s what happened.”
Jessica: And so documenting it so that the next time you can say, “Well, I told you so, this was a terrible idea.” Unfortunately…does anybody else have any advice around this?
Man: send angry tweets, you know, take this.
Jessica: Fight with them on the internet?
Woman: Nicely.
Jessica: Nicely.
Man: Subtweets on it.
Jessica: Subtweets. I just thought I’d dance for a little while.
Man: Well, the thing is like as you mentioned about the email, they say, like, they’re going to put…not your name, the name of Jen…
Jessica: Jennifer, too.
Man: So, the thing is like Jennifer, she’s known on the internet from personality and on the site. So, sending that email is not like, the reply will go like, “Bullsh*t, we know that.” So, sending that cold email between in a way I know that it’s not fair. So, her value on the internet will even be more negative towards the company because basically people will know, “Oh, she works more.” Yeah, that’s it.
Jessica: So, reasoning them through it and be like, “Hey, you’ve hired me, and you think I’m great. Here’s how you’re making me less great.” So, these are both very, very good advice and I’m so sorry, this is terrible to admit in a conference talk, but my advice for this is not good advice at all. My advice for this is that if you’re in a position where people are asking you to do something that’s terrible for developer relations. It’s terrible for your product. It’s a bad idea. There’s nothing you can do. They won’t change. They won’t move. They won’t listen. You have to make a decision alone. Is this something you’ll do? Is it okay? What will you do instead? I can’t tell you what to do here. Do you fight with them on the internet? Do you walk out? Do you smash things on the ta…do you quit? That’s a question for you alone. I’m so sorry that I can’t help you.
Thank you very much.