In this talk from DevRelCon London 2019, Shy Ruparel talks about the challenges practising dev rel in a company whose customers are larger enterprises, the experiments to address enterprise developers, and the metrics that help keep his CFO happy.
Shy: I’m Shy, I’m a Developer Evangelist at Contentful. I’m really excited to be here surrounded by my peers. I will be honest with you, I am about as nervous as the first time I ever gave a talk on stage. I imagine your expectations of talks is a lot higher than the traditional Developer Community so hopefully I can live up to what you all are expecting.
Before I really dive into the meat of this talk, I really want to give you some context. I found watching previous talks from DevRelCon, the more context I have about the speaker and about the organization that they’re coming from, the easier it is for me to translate the advice and rerun the experiments that they share at my own organization. This isn’t just me aggrandizing myself or bragging or anything, this is hopefully a little useful.
I’m a strong believer in Developer Relations. I think regardless of where Dev rel is in an organization, dev rel is a force multiplier. I think it’s great. And I’ve committed my entire career to it. I started off at Major League Hacking five years ago, supporting student Developers, having them learn all sorts of amazing things with a lot of partners that we got to work with at the time, and for the last two years, I’ve been at Contentful. I hit a point at Major League Hacking where I wanted to expand beyond explaining how MPM worked over and over again and go talk to some folks that are a little more senior in their careers, and Contentful has really enabled me to do that.
Contentful, let’s talk about the organization that I’m representing. We’re a headless content management system as an API. We have about 400,000 users on our platform that’s a mix of traditional Developers, nontechnical Content Creators, and nontechnical Project Owners. We enable all of these folks to work together in a really powerful, seamless way. Our organization itself is heading towards about 300 full time employees by the end of the year. When I joined two years ago, we were at 200. Part of the growth during my tenure at the organization has involved us raising a Series D round, so we moved from being a Series C organization into a Series D organization and most recently we actually just hired a new CEO, so we’re having some executive shake ups, which I’m really excited about and I think is going to be pretty good. But overall, it’s a lot of, I think, pretty healthy signals for the size of our organization and the age of our organization. I don’t think we’re doing anything out of the norm for where we are organizationally.
And then our dev rel team at any given moment is about three people. Now I don’t want to dive into the challenges that you encounter as you transition between different stages in company growth. I think there are a lot of really excellent talks already that cover that, and I do want to highlight Dana’s talk from DevRelCon San Francisco. It’s up on YouTube. I’ve done by best not to duplicate her information because I think that talk is actually really excellent and I’d really encourage you all to check it out if you haven’t had a chance to see it yourself.
With changes do come new problems. When I interviewed at Contentful, our organization was pretty into Developer led Marketing. At the time, about 90% of our Marketing Department’s budget went straight towards Developers. And as the company grew and the organization changed, priorities started to shift, and things are pretty different at Contentful now. Developer Marketing is still a big part of what we do, but it isn’t a majority of our time anymore. And with these changes, I think it’s really important that we have a great strong Executive Sponsor. This is Chris with the headband, he’s our CMO at Contentful. And Chris really understands and really gets what dev rel means and why we’re valuable. Even though the priorities of our Marketing Department are shifting away from Developer Marketing, I feel pretty confident in the work that I’m doing and the expectations of the outcome.
To take a brief moment, I actually don’t really care where dev rel sits. I know there’s a lot of conversations in this community about what are metrics, what department should your Developer Relations team be in, and should you be an advocate or an evangelist? I hear Joe Nash has a lot of really strong opinions on that. And I would encourage you to go bother him about it, but I don’t actually think any of that really matters. At the end of the day, what I really care about is enabling and empowering Developers, and I can do that in Marketing, I can do that in product, I can do that in engineering, or if the company exists to service Developers, like Major League Hacking did, I can do that, too. And I think Brandon of AWS actually put this really well, that as a community, we really need to walk away from talking about what titles and departments we should be doing. That’s my one small tangent.
I have a few problems at Contentful, and I’m going to take this moment of catharsis to vent. You’re all my therapists right now, so thank you for volunteering for the emotional labor. At Contentful, one of our major problems being an enterprise organization, and you might’ve guessed this from the title of the talk, is that Developers aren’t actually the people that make the purchasing decision of our product. Out of curiosity, is that a familiar thing for people in the room? Raise your hand, I see a few people. Oh wow, a lot of people. Okay, that’s great. You all should come up here, I don’t need to give the talk.
Contentful itself is a pretty powerful tool, which means it does actually come with a learning curve. You can’t just deploy Contentful to your project in five minutes, unfortunately. I don’t have a five minute demo. I’ve been at Contentful for two years, and I couldn’t do a five minute demo right now. Our tool doesn’t really enable that. And then there’s a layer between Contentful and the Developers themselves. Having an enterprise sales cycle that means there are account owners that represent the enterprise organizations that we’re working with, and those Developers need to work with that account owner to talk to whoever’s on the Contentful side. Dev rel exists to route around that. And then we have all the traditional Developer relations problems. How do we empower our Developer community? What do they need? How do we make sure that our success is being tracked and being measured? And we’re getting burned out all the time too, just like everyone else.
Let’s talk about the Contentful Developer Community. Ideally, these people have heard about our organization before they are told to use Contentful. Maybe they’ve used a personal project, but since we’re really most effective when you’re having Developers and nontechnical Content Creators and nontechnical Project Owners collaborating and working together, odds are if a Developer has used Contentful in their personal time on our free plan, it’s not necessarily fully representative of the potential of our platform. Diving into that purchasing problem a little more, the final decision about Contentful is made by someone else, although Developers might be contributing and advocating for a certain platform usage when you’re looking to revamp your content infrastructure, the Developer generally isn’t the one with the final say, and so making sure we equip them with ammunition is really important. And then also, the mastery is really hard. It’s a tool that takes time. You got to understand content modeling. It’s really complex, I would argue that it’s an endless thing where you can always learn more, just like any significant technical concept. And then also, I have to deal with sales, customer success, and partnerships.
The worst part about enterprise is this extra layer that I was talking about, this layer that lives between our Developer Community and me. And having proactive buy in from those groups is hugely important. If an AE or a CSM doesn’t respect what I’m doing, it causes a huge amount of friction. It makes it very difficult to talk to someone that might be an active or prospective customer if those folks don’t trust us. It’s really important that we’re establishing that.
To dig into that a little more, who do those AE’s and CSMs talk to? They’re not talking to the Developers, and odds are if they’re getting a technical question, it’s routed through an account person on the other side, typically a nontechnical project owner. Most Developers will never get a chance to connect with that Contentful account manager because of streamlined communication channels and having a single point person in both directions. And then yeah, metrics. The forever problem. This is our CFO, Marcus Harder. He is my, he’s great, but if I can’t abstract what our team is doing into a spreadsheet that Marcus can pull without talking to me, Marcus is going to be angry. He’s going to start advocating to get rid of our team whenever a recession happens or a belt tightening needs to happen for whatever reason. That metrics problem is still forever there, even in the enterprise world.
Let’s talk about the mission of the Contentful Developer Relations Team. Goals come and go, quarterly KPIs change as the seasons do, but regardless of what happens, the mission of the Contentful Developer Relations Team stays the same. It sticks and it’s been here basically, as far as I’m aware, the entire institutional memory of the team has been about awareness, education and community. And hopefully this sounds really familiar to everyone in the room, regardless of what kind of dev rel you’re doing.
Let me dig into how we achieve those three things. When I’m talking about awareness, I’m talking about traditional dev rel awareness. Does the Developer Community know who we are? And this one’s really easy. I know how to do this. I knew how do to this five years ago when I started working in dev rel. It’s going to events, it’s sponsoring meetups, it’s speaking at conferences, it’s building really excellent technical documentation, it’s having a presence online and offline, and the specifics of how we execute on it, I don’t think actually hugely matter that much. And I don’t really want to dive into it too much because you probably have your own version of how you run things. The only major change is occasionally I have to wear a dress shirt. Instead of having my company logo, I have some buttons.
At the end of the day, it comes down to Developer awareness of our dev rel team. We want those Developers to know that Contentful exists, be excited when they’re being asked, “Do you want to use Contentful?” and then when they are existing and active customers, we want them to know that the dev rel group is there to support them. Of course we’ve got customer support for your major crises, your outages, your incidents, but for simpler stuff like how do I do this specific feature or I want to have a quick chat with someone about content modeling and what do you think about the way I’m configuring my site? dev rel has, I think, a really powerful quick feedback for that loop. We do a lot of things like having Slack communities, we have a forum, we have an active-ish presence on Stack Overflow as we find the time for it, and we try to really be there for our Developers and have them know that we’re available.
One of the things I do every month is I send out a newsletter with my face on it, partially because I want those folks to have a great morning, but also because I want to remind them that we exist and we’re available, and I end that newsletter every month with, “If you need anything, please come reach out. Here’s how.” When an organization is evaluating a platform, I want Developers to be shouting at the purchaser, “You have to go with Contentful.” I want them to be the internal champion, and the only way they’re going to do that is if they feel supported and empowered.
Education, again, I don’t have a ton I think is really different, in terms of education in self service versus enterprise. I think actually largely, they’re pretty similar, but I do want to highlight it briefly. So, I think for most of us, when a new feature comes live, you’re usually the first customer. This is a photo of me winning the New York Halloween contest for Contentful. I was the only entrant because I work remotely, but I’m still proud of that victory.
We have a new feature that is now available, scheduled for publishing, helping to give feedback on how that feature should work. If our engineering team was looking for input from a self service customer or a pro bono customer, I’d be able to help drive that. But really, I’m the person using the API for the first time right before it hits production ready and it goes out to our customers. And most importantly, because I’m doing that, I’m also the one doing those initial tutorials and educational items. The quick and easy, how to use Contentful on Graph QL in five minutes tutorial, that comes from our group. And that is really all about expanding the level of Contentful mastery in our community. Education is a huge core component about what our team does.
These tutorials actually go on to influence people more than just the Developers. Our sales folks, our CSMs, our partnership folks, they take a look at it. We’re directly enabling them to showcase use cases, and even though my intention isn’t to make content for them, they have actually dedicated people that build amazing white papers and phenomenal things that aren’t silly IoT projects that they can showcase, I really do hope that they’re able to re-utilize and do things. And ideally, a sales engineer is going to take a look at something that I’ve done, take it out in the wild and come back in six months and be like, “You know what? We’ve battle tested this in an organization, let me give you some advice on how to update best practices and best feedback, and let me give you some advice about how you as Developer Relations should be evolving, how you think and talk about the product.” Because I’m talking out to an audience as a one to many person, whereas a sales engineer is talking a one to one, and so there’s a level of granularity and detail that they’re able to give me that I just can’t get, unfortunately.
To be clear, I’m not a Learning Services team. We do have a Learning Services team, and they’re great. And for them, they also find a lot of value in the tutorials that we do. A lot of their first drafts actually come from content that we’ve created, and I’m totally fine with that as long as they’re providing the feedback back to me. And then community. This is my favorite part of my job is the community. How do I support and empower the Developers that use us or might use us in the future? But to really do that, I think there’s a lot of really important questions that we have to run through. Who is the community? Are they in certain cities? Do they like to go to events? Are they older Developers with families and so it’s really difficult for them to make a meetup? They have to go home at 5 and pick up a kid or deal with an elderly parent. Answering that question, I think is really important for your organization as you decide how to do things. What are they making? If you see your community members making a lot of stuff, the same stuff, maybe that’s something you should be taking to your product team. Are they writing tutorials and blog posts? Can I elevate and empower and give them a platform and then can I pass that information and feedback on to some of those more business units? Are they extending Contentful in really interesting ways? What are they doing? And what do they need? And this is really the most important thing. Finding out what support and resources our community needs is a really difficult job.
We have to spend a lot of time in our community to figure it out, just listening. And you might be wondering why is this important? And I want to reiterate, I actually expect that a lot of folks in the room already have a good sense on why community is important, and it’s really about enabling Developers to be successful. These Developers, even though they’re not purchasing, are hugely influential in landing and renewing Contentful. They’re the ones who have the ability to completely tank a purchasing decision or to choose us over someone else. If I play my cards right, as a Developer Evangelist out in the field, I can trigger an expansion. But beyond the money stuff, I think we have a great product and I think our product actually does make Developers lives better, and if we’re not doing that, I want to know about it. They’re our champions and I want to treat them really really well.
The persona of an Enterprise Dev is very similar to the persona of a Developer that is doing the purchasing decision themself, it’s as wide a population as most traditional Developers. There are folks that are at all the meetups, there are folks that are at none of the meetups, there are folks that exclusively engage with us online, and then there are folks that only hear about us because they Google an error that they’re getting and the first post they get is a Stack Overflow thing from five years ago.
Extra areas where community is really important are for things like Analyst Reports. Who here has heard of something like the Forrester Wave or the Gartner Marketing Report? Okay, so a decent amount of the room. One of the things that both of these organizations look for, and for the folks that haven’t heard of them, these are Analysts that put out reports that I think are pretty influential for larger organizations to figure out what technology vendors they should be working with or they should be investigating, and being on one of these reports when you’re a larger organization, or you’re an organization that lives on enterprise sales is hugely important. Our PMM team at Contentful spends a pretty nontrivial amount of time on working on these reports, and occasionally, we get roped into being part of it as well. If there are technical questions that these Analysts need answered, that’s when dev rel can step in and really give an assist to some folks in our organization. But one of the things they do ask for, and is a major indicator, is how healthy is your community? If you have a healthy community, it’s a really good signal to these organizations that you’re someone that they should be including in their report, and if you can get on that report, that makes your folks in your Marketing Department very, very happy.
I’ve talked a little bit about our mission at Contentful, and this hopefully should sound pretty reasonable, but we have a secret mission on the dev rel team, and that secret mission is really the biggest challenge, I think, between running Developer Relations for an enterprise organization and running Developer Relations for an enterprise, and that’s actually all internal awareness. Now, I’m not being measured on internal awareness, my KPIs are not triggered on internal awareness, nothing financially or quantitatively is driven by me doing internal awareness, but for my ability to achieve my goals, I need to get people inside my organization to be onboard with what I’m doing, and I need them to trust what I’m doing with my time. The gut response from a traditional Sales or Customer Success Manager or Partnership person when they hear that someone is talking to an account that they’re responsible for is, “Well s***, who the f*** is messing with my messaging?” and I hate to be terse, but really, that’s the level of response that you get. The default state between any Developer Relations team and any sales team is friction. If you’re not proactively maintaining and expanding that relationship, you are eventually leading yourself up to get in trouble. You have to be involved, and you have to spend time building rapport and building and maintaining trust. I am always running into situations that I don’t have documented on how to deal with, and if those folks don’t trust that I’m on top of my shit and I know what I’m doing, they’re going to come yell at me and they’re going to make a huge rant and that’s going to derail my ability to empower the community.
One of the easiest things I can do to build that trust is actually log and document everything. One of the perks about working in a Marketing Department or working at an organization that has a Marketing Department is that I’m surrounded by people who deeply understand Marketing data and the tools that you use to measure that stuff. Tools like Salesforce or Marketo or Looker are really really powerful and I do not understand them at all. I can take a look at a report and know I’m doing well, but building the campaigns in the correct way, or understanding how we should be structuring things so our AE’s can do their jobs as efficiently as possible is something that just doesn’t come to me. I think Python’s easier. But documenting all of this work is really important, so I want an SCR or and AE to take a look and see, this is an account I’m talking to, dev rel has talked to them, and wow, this is an easier account for me to close because dev rel was part of it. And it’s not a huge ask for our Marketing group to help with this stuff. They’ve definitely sat down and they’ve taught me how to do it. If I’m willing to show up having the data formatted in a way they can work with, they’re willing to sit down and give me the assistance that I need to make sure that things are being documented appropriately, that the Looker dashboards are being built, and I’m achieving what I need to essentially maintain a job. You remember Marcus from before? This is the work that really makes him happy. If he doesn’t have to talk to me to know I’m driving value, he’s really happy. And to be clear, I know our metrics aren’t painting the full picture. I’m not going to tell you what our metrics are, because I don’t think that’s helpful, unless everyone in the room wants to give me a business card as they leave, there’s no way I can log the impact of this specific talk, right?
The metrics that we track exist as a baseline. And it’s really important, again going back to that Executive Sponsor, that they know that what we’re doing is actually just some small percentage of the actual impact that we have and that there’s some dark magical number that’s a force multiplier. Rob Spectre I think put this really well, the outcome I want is I want sales reps to say that “Leads that come out of dev rel are the best leads.” Yeah, and talking about those folks in Marketing that are supporting me, I really want to make sure I’m doing a good job of supporting them. And again, I’m not getting measured for this, but making sure that I’m building political capital with those folks so that when I need something from them, they’re excited and they want to help me.
I try to give a lot of technical overview to our blog posts when they ask for it, I help source content for our Marketing Communications Team to put on our blog posts, I support our Field Marketing Team by going to events that I really don’t want to go to and occasionally, I visit customers and do the one to one relationship rather than the one to many, and that’s something that’s really powerful for our Product Marketing Group. Whenever there’s a feature launch, I want them to want me to be involved and the only way I can do that is if they trust and they know that I’m available. It’s a huge part, I think, of having a successful feature launch is having dev rel be part of it.
Being engaged in the organization in general. I want to be part of all the pricing committees that spin up, I want to be part of the engineering decisions where they’re talking about features, if there’s some sort of formal conversation happening at our organization, if it impacts Developers, I want our group to be part of it and I want that to be a thing that they implicitly just know. They send us the calendar invite, they don’t even have to ask for permission, and it’s really important that we’re engaged and we’re involve in those meetings as well. And then being involved in the company culture as well. I’m not in our office 100% of the time. I fly to Berlin once a quarter and I spend a lot of that time just socializing with people and building rapport, running Dungeons and Dragons on buses and chatting and drinking coffee. I think one of the best things we did as an organization this year was hire an Evangelist in San Francisco, so we have that same relationship in our San Francisco office as well.
Being seen as the expert. I want to teach Contentful to people at Contentful. I think there’s a really magical story there of having a CSM that’s been at Contentful fairly recently, I show up to Berlin on Monday and I’m able to give them the experience of writing code and getting to their first website, having it so they can make changes with our API and see how that updates. That’s given those people a much deeper understanding of how our product works and they’ve developed that understanding because of our team, they implicitly trust us now and they’re not going to worry when they see my name attached to what they’re doing. ‘Cause at the end of the day, it’s all about internal buy in, right? We’re a team at our organization, and even though I have no desire to go do Sales, I do want them to be successful and I hope, even though our Sales team doesn’t really have a strong desire to teach Developers how to script a migration, for whatever reason, they want me to be successful. And if you take anything away from this, it’s spend time building that relationship. And Developers are still hugely important, but the folks inside are just as important.
That’s it for my talk. Unfortunately, my boss has gotten a promotion, so I do want to take this moment that if this sounds like we’re doing great and you want to come be my new boss and help us evolve our dev rel program, we are looking for a new Head of Dev Rel as well, and I’d love to come talk to you. But that’s it for me, thank you so much for your time, I really appreciate it.
Indeed has seen a huge uptick in Hacktoberfest participation from their engineering team. Hear how they did it.
People were organising communities long before developer relations. So what can we learn from those that went before?