Connecting DevRel & Sales: A Case Study

My name is Sara Varni, and I'm the CMO at Twilio. I wanted to share with you my learnings from the last three years that I've been at Twilio. A topic that's near and dear to my heart, and that's how a developer relations team and the sales organization can partner well together. I hope by the end of this session that you learn something, that there's something that gets you excited. I think if I had to sum it up, the TL;DR of my three years is that at the end of the day, these organizations aren't as different from each other fundamentally as people might think or people assume. Hopefully some of the tips I've learned over the last three years will be helpful, but let's just jump into it.

Who Twilio Is & How We Got Here

Just a little bit about Twilio for people who aren't familiar with the company, we started in 2008 and it started actually when Jeff Lawson Rickrolled someone on the stage of TechCrunch Disrupt, and it started with a voice API but led to a series of communications APIs across a number of different channels from SMS to video, to email. We even have an IoT product, and most recently we've entered the contact center space, given our history in communications channels. Today we're proud to be operating in over 100 countries and we have over 170,000 customers. Most importantly, we have 8 million developers that know and use Twilio.

Twilio Was Built on Developer Love

Twilio was really built on developer love. We've always been a super developer-centric company and were almost entirely self-service up until about three years ago. But over time, as we started to move from SMB to mid-market and then up into the enterprise, we realized that we needed more hands-on account support. As customers began to spend more and more with us, we found that some of them might disappear without a lot of communication with us because we didn't really have the relationships in place. Seeing that, we decided to build out a go-to-market team and the sales team more in earnest. Our joke because of that is that Twilio is now a 12 year old company with a 3 year old sales team.

So when I came to the company, I saw a huge opportunity to connect this developer community and our incredible developer relations team with this growing sales organization, and really use both of those teams' superpowers to drive the most impact that we could for Twilio. But as you can imagine, that's a dance that you have to do. You have to be careful not to lose your credibility with that developer audience, also while being action-oriented and making sure that you're aligned to corporate goals and to what that new sales organization is trying to do.

Bridging the Gap Between Developers and the Business

So, over the next 20 minutes or so I'm going to walk through some of the tactics that we've used to really bridge that gap between developers and the business. I think it starts by finding that unifying metric.

1. Finding a Unifying Metric

I think often when you go down this road and are trying to think about, "Alright. How can I make the most of all of this great developer activity I have in my company with this go-to-market organization?" There's sometimes this perception that it's just oil and water and there's no way that you're going to get the teams to ever align, so as I was thinking through this presentation I thought through some of the people internally at Twilio who have been instrumental in driving this change with the company.

We have someone like Greg who runs our developer community, he's super passionate and has been at Twilio for a number of years. He can name some of our earliest customers and just has a great reputation with our developer community and customers in general. Then we have Stevie, one of our most prolific enterprise sales leaders. She is great at creating a vision for our customers, great at being side-by-side with them and really helping them think through some of their customer engagement challenges. They're both just great, phenomenal leaders at the company.

Developer Community Leads vs. Enterprise Sales Leaders

But obviously, when they wake up in the morning they're motivated by very different things. You think about Greg and what motivates him in his role, he's going to be focused on things like developer sign-ups. How many people is he adding to that Twilio community? Developer activation, once he gets them into the community are they actually doing something with the tools? Are they making it to meaningful milestones with Twilio? Then, are they coming back to do more? Or did they just do a project and we never heard from them again? But are they coming back on a regular basis to see what's new with Twilio and to do more on our platform?

Then you think about Stevie as our sales executive, she's got a completely different set of metrics that motivate her. It might be enterprise pipeline, how is she building more and more opportunities for her business so that ultimately she's going to hit her quota. New bookings, and ultimately revenue, after she's signing on these customers are they meeting their forecasts? Are they continuing to build on Twilio and drive usage of the platform?

Just looking at these two, it might be hard to figure out. "Alright, how can we really align these two worlds and get people working together?" So we all teamed up, we came at it from both sides, coming at it from a humble perspective of not knowing everything that we know about the respective functions, and we decided "What is that intersection of these two groups? Twilio is trying to move to the enterprise, we're trying to move to bigger and bigger customers."

The Conjunction of Developer Signups

It could be easy to go at it from a number of different ways, you can think about, "Let's just go after certain programming language, let's go after a certain territory." There's so many different ways that you could slice and dice it. We decided we wanted to eat the elephant one bite at a time and we landed on developer sign-ups in a particular segment of our enterprise customers.

Now, this might sound simple and you're like "Yeah, of course. This is not rocket science." But it was really critical and we spent a lot of time getting to that metric so that everyone was clear on what the priority was. If we're going to do an event, who's it geared at? It really helped us fine tune the programs that we were going to deliver. Also, I think a byproduct was just having the conversations about what's meaningful to these two groups of people and figuring out where these intersections exist in the first place.

2. Identifying Pivotal Moments

The second piece is really identifying the pivotal moments in a developer journey. One of my long standing jokes is that "Rule number one of marketing to developers is 'Don't market to developers.'" I think you really have to come at it from a place of being helpful and unblocking parts of your process so that developers can continue to do what they came to your website to do and get moving with their project.

Breaking Down the Opportunity Journey Analysis

I anonymized this particular opportunity, but at Twilio we do a lot of opportunity journey analysis. We look at all the activity from when someone first comes to our website and signs up for one of our APIs, to when they actually become a sales opportunity in Salesforce. We look at a lot of these just to see the patterns and trends, and to see how we can fine tune this journey.

Developer Sign Ups vs. Enterprise Projects

A couple of things that I think have come out in this experience for me-- first off, if we see a sign up and then there's five different content downloads or people are looking at docs and then they go to an event and then they ultimately become an opportunity, we're always trying to think about what are the ways that we can optimize that journey and really shorten that fuse between developer sign up and an enterprise project?

Arm both sides of that equation, making sure the developer has all of the tools and resources to skill up and to learn what they need to know about your platform. But also on the enterprise side, are we communicating the value to the enterprise buyer and the person that might ultimately hold the budget to say, "This is why you should be thinking about contactless delivery right now." Or, "This is why you should be thinking about moving your contact center to the cloud," so that when the developer does go to their PM or vice versa, they both know what value Twilio brings to the table.

Shortening the Fuse: Help, Don't Sell

But a couple of things that we've learned over the course of the way, I think it goes without saying is, when it comes to developers, you need to earn the right to communicate with that audience. You need to make sure that you're not leading too much with your products and features and feeds and speeds, and really coming at it from a place of helping them. I think a lot of that can be done by recognizing how they came into your site, what they were looking to do, and then providing the right nurture and follow up to make sure that you're helping them along that journey.

I think another thing that bridges that gap and shortens that fuse between that developer interest in what's happening in the business, is packaging up things like your documentation and packaging up things like blog posts that really get to a use case as opposed to an individual API. I think that helps the product managers and solutions architects that sit in middle, picture how some of your individual products could come together.

I like to say that the scenarios I'm talking about are very Twilio-centric and centered around are our products, which are API-based. But I think there's different approaches-- if you're supporting a product that's completely out of the box, or if you're more of a SaaS solution. I'm happy to talk through some of that during the Q&A, as I spent 10 years at Salesforce and have definitely lived in the SaaS space.

I think another important component, and I've seen this across the board in my experience as a marketer is

The more you can connect your existing community members to new members I think the better off that you are. I see some people hesitate to do this because they're nervous about what a customer might say to a prospect, but I think if they're going to invest the time to engage with your community most often they're going to have positive things to say.

I just think it's a way to accelerate development on your platform, and I think it's a great way to cut through some of the marketing fluff and get to really what a developer is looking to solve and to help get them through their problems. I think there's also an argument to provide tools for developers to sell the value of the project up the chain to the business owner or the person that's holding the budget, so things like ROI calculators where you can show comparatively if they're to implement your tool, what the value that is going to bring to the company.

You really want to be as hands-off as possible and helpful, pushing and helping them along the journey, making sure that they're not reaching any blockage in your product. But when they do appear to be looking for help, and we look at a lot of signal in our base of developer sign-ups, there is a moment when you do want to bring that sales team in so that they can get them the right support. Especially as you are dealing with bigger and bigger customers, they might want intros to your professional services team and they might need help with solutions architects on your team, or solutions engineers.

To the extent that you can identify when a developer really does want to engage with your customer-facing teams, I think it's important to make that connection. But I think it goes without saying, when a developer signs up for your product. the first thing you shouldn't do is get your inbound sales team to go and qualify that. Because that is going to be not a great experience for either side, and I think you need to figure out other ways to move them through your product funnel.

3. Empowering and Training

The third area that we've really focused on is how you can empower and train people that are learning about your platform and getting up to speed. I think sometimes when you have started as a company focusing on SMB and mid-market, there's a perception that enterprise developers don't want to be innovative. That they don't want to focus on new cool projects, and I think it's been really interesting to see our developer evangelists at Twilio start to engage more of their enterprise accounts and watch how that perception has changed.

We do what we call Enterprise Hackathons at large enterprise companies, where we'll bring some of our developer evangelists on site to our customers, pre-Covid of course. But we've actually created a virtual version too. Back when it was in-person, the customer would come with a set of use cases that they wanted to tackle and they would hack together on them all day. At the end of the day, they do a presentation back to the business and it's a great program in that these teams get scaled up on Twilio in the course of a day, and for their counterparts in the business, they're excited to leave the session with some early proofs of concept of what Twilio can do.

I have this this image up because at one of these enterprise hackathons, we went to a large customer-- they'll remain nameless, but in the break room they had this sign by the actual television that said, "Please do not try and change the channel." One of our developer evangelists commented on the fact that these enterprise developers, they want to do cool and innovative things at their company but they're not even allowed to change the channel of their TV.

It was just a joke that we had internally, but I bring it up because I think once our team had gotten on-site with some of these enterprise customers and teams, they realize that they're not all that different from the startup developers and some of the smaller developers from smaller companies that we've worked with in the past. They want to be innovative, they want to bring new ideas to their company, they're just not always equipped with the tools and the freedom to do that.

Superclass & Engage, Foundry Workshops, and Enterprise Hackathons

So we really tried to design programs with that in mind, and how we can give them new tools in their tool belt to use and create the best customer experiences that they can. So, just three programs to walk through that we've established here. One is our Superclass program. We do this in parallel with our road show. We have a road show called Engage where we go and give an overview of what Twilio does, our platform, the business value of it. It's really generally geared towards product manager or head of contact center or more of a business audience.

But alongside that, we have a Superclass which runs in the morning and we encourage developers from the same companies to come and to get hands-on with the product. We take them through our virtual learning platform called TwilioQuest. It's a gamified platform where they learn through different challenges and earn points over the course of the day. We love having this approach of having both this technical session as well as this line of business session, to bring both groups together and to hear the sides of Twilio that are going to be most relevant to them.

The second is foundry workshops, so we're a platform company and sometimes we come to customers who know they've got customer engagement challenges, but they don't know exactly how to solve them. So we'll bring in a team of design leaders from Twilio and we'll sit down with both developers and the line of business to map out a customer's cool customer journey and say, "OK. Here are the rational places where Twilio can help. Here's where some of our partners or other solutions could help."

We like to make developers a part of that process, so early on they can weigh in and say what's going to make the most sense for their business and in the context of what they're already using.

Then a third way we do it is those Enterprise Hackathons. I talked a little bit about it already, but it's just meant to get people on-site and engaging with customers, helping accelerate some of those proofs of concept that they otherwise might delay or might take longer had they not had the hands-on expertise right on-site. This has been a win-win for both our customers and our sales organization. It's been great for these customers to get scaled up on Twilio in the course of a day. It also helps accelerate that proof of concept cycle for go-to-market teams, and keeps projects moving along much more quickly.

4. Playing to Your Strengths

I would just say, just some commentary on how to execute it. I think everything can look good on paper, but at the end of the day you need to make sure that people are motivated to do this, that they don't feel forced to change the way that they've been operating for years, and I think that there's an art to that.

Harnessing Your Team's Strengths Without Changing Them

I see a lot of our developer evangelists super willing to help out with our sales organization and to get in the trenches with deals, but sometimes they don't know always how they should insert themselves. I think it's important to be prescriptive. How do you want them to participate in a meeting? How do you want them to be part of the process? I think rightfully so, some members of the DevRel team might be concerned that they're going to just be in this deal monkey cycle where they're constantly having to work on demos or PowerPoints. You want to make sure that you're setting the ground rules early so that doesn't happen, and that people are still able to do the core of their day job and really what their job description looks like.

I also think bringing your DevRel team into your sales organization or blending the two, it's not a fit for everyone. You have to recognize the people who are interested in this kind of work, and then there are people that aren't. I just don't want people to walk away saying, "OK. I'm going to turn my DevRel team into this Secret Squirrel sales team tomorrow," because I don't think that that's the right approach. But I do think having your developer evangelists do a tour of duty with some of these customers can be really helpful and help them in their day to day, even if they're not, moving forward, going to be exclusively focused on working with enterprise customers.

Again, it always comes back to that helping versus selling. I would think of using your developer evangelists and your developer relations team as more of an extension of solutions engineering. I've seen some incredible work happen across our two teams at Twilio during Covid, where our documentation team and our developer evangelists are building a lot of content at the API and product level, but our solutions engineering team who's out in front of customers quite often-- we're hearing about new use cases that were coming through Covid.

So we married those use cases we were hearing with the content that we already had in our developer library to repackage things aligned by use case. Instead of having things at the individual API level, what is the tutorial to help someone deliver on contactless delivery? So I've definitely seen a lot of great synergy coming out of those two teams in the wake of Covid, and I just think it's something to keep on your radar and think through as you're trying to think about how you can bring these worlds together.

5. Scale: Final Thoughts

Finally, I just want to add some final thoughts on scale. I know many of you are operating companies that are that are smaller, relative to a Twilio.

You Don't Need an Army

But I want to assure you that we don't actually have a huge army assigned to this as an effort at Twilio. I think we've still been able to achieve some pretty phenomenal results, but a couple of things that I was thinking about as I was building this out, it's very easy for me to say this now given that everything is digital. Always think about digital first, so for all the programs I was talking about, whether it's Superclass, whether it's Foundry or whether it's our Enterprise Hackathons, we have virtual versions of these. That will only help you scale.

If you always have to fly people to a city, fly to people to do something, that's just not going to scale to thousands and thousands of customers if that's what you need. For all of these, I would just think about "What is the digital--?" Of course, sometimes face-to-face interaction, there's nothing that can replace it. But I do think for all of these things you should be thinking about "How will this transfer digitally, and can it scale?"

I also encourage you to find leverage points in your community. We have some people who are so super passionate about Twilio, and we have often packaged up some of the material that we have. Whether it's that Superclass curriculum for some of our big influencers and community members to drive that on their own, so that they can host their own Superclass or they can even host their own virtual hackathon.

I think you'd be surprised at, especially for people who have huge brand affinity for you, the lengths that they'll go to, to share what they've been doing with your products.

I would just be on the lookout for who those influencers and key committee members are. Then I always advise people to really think about a "Train the trainer" method. At Twilio our sales organization is growing much faster than our marketing team, for example, or our DevRel team. So I'm trying to think about ways that I can put this program in the hands of other teams that are growing faster than mine.

For things like the Enterprise Hackathons, while our first iterations of them were very heavy in terms of our DevRel participation, we've tried to increasingly think about, "what are the tools, what's the playbook and checklists and all those things that we can hand to our solutions engineering team, so they could deliver them without us being in the room?" Because their team is growing, like I said, more quickly than ours. That's just another leverage point for us as a marketing team.