Reactive versus proactive strategies for developer relations


DevRel has been around long enough for companies to expect some degree of accountability from the teams charged with interacting with the tech community at large. In her DevRelCon London 2017 session, Jessica West, resident Algolia developer advocate, muses on reactive versus proactive approaches for demonstrating value. Expect war strategy, insights into the Risk playbook, and some upfront money talk.



The best offence is a good defence. Generally, the idea is that proactivity, a strong offensive action, instead of a passive attitude will preoccupy the opposition and ultimately hinder its ability to mount an opposing counterattack, leading to a strategic advantage. However, defence is not necessarily the best offence in DevRel. Today, we’re going to talk about strategies around developer relations, what works, what doesn’t, and how you can set up your team for success.

Who am I? That’s me with my favourite kissy face. I’m Jessica West. You can find me on the internet here. I love working in the community, taking ridiculous selfies, writing new apps, and, of course, the occasional karaoke. So come find me on the internet.

DevRel on the rise

So shiny toy effect. As many of you know or have heard from a certain other West cum Brandon West, developer evangelism isn’t really a new thing. It’s actually been around since the ’80s, 1982 as far as we can see from Apple. However, in 2010 when Twilio hired their first developer evangelist as more of promoting a product type of approach, this became kind of the new hot thing, and a lot of companies were really interested in hiring their own kind of developer relations program. And we started seeing more and more companies bring this type of department to their teams.

So talk about the game of risk. In risk, one’s ability to build up armies depends aggressively on attacking so as to acquire territory. However, in risk, the luck of rolling of the dice is ultimately the determining factor. Players who fail to do so in constraint instead of holding the line against the enemy attack will likely end up in a weak position. In-depth info argues that this adage does not always apply. When the battle rages between two players, one should put every ounce of player in the offence. However, when several players are involved, the political element can change this dynamic.

Conferences, for example, can be a roll of the dice. Some things that you think are gonna be amazing maybe not turn out so well for leads. And then some others that you’re not quite sure about could be a huge turnout for you and your team. It’s all a roll of the dice. So the game of DevRel, why we’re all here. In DevRel, one’s ability to present a concept and a product often depends on maintaining the contact with the community, for example, making, attending a series of events, presenting a series of code, or writing a series of blog posts.

Trying to do it all

To be successful, you need to stay technical, write content, and be friendly enough to manage events. People want to come talk to you, all while appeasing the executives in other teams, which is where things get tricky. If you aren’t proactive with your strategies, your team will fail. I had the amazing opportunity to speak with multiple people in the industry about this topic. And some of you are in our audience, so thank you all who did give me an hour or two of your time and all of my follow-up questions. I really appreciate it, and I’ll be sharing some of their thoughts throughout this presentation anonymously, of course, to protect the innocent or not so innocent.

So we focused heavily on reactive work due to a lack of tools and resources to be more proactive. I swear I didn’t pay them to say this. The DevRel team was not specifically being measured. Those measures were maintained and reported, but they weren’t held accountable to. What do reactive strategies look like? Reactive, by definition, is acting in response to a situation rather than creating it or controlling it, so reactive approach.

In DevRel, we touch a lot of different departments. It’s part of our… And, like every aspect of our business, it’s certainly quite a task. This looks really pretty, right? If you saw this, you’re like, “I wanna get in DevRel. I wanna do all these things, community, create, API content. This is awesome.”

Man: This is the reality.

Jessica: This is the reality. It’s too much. It’s literally… This is what your inbox would be if we did every single task that everybody came up and asked us to do, resulting in your inbox looking absolutely ridiculous. You’re trying to put this all in your trello board, and it’s not working. And this is actually a big list of what I compiled from asking people like, “What do requests look like from coming in from your department?” “What do you do on a day-to-day basis?”

So what you think DevRel looks like, what it actually looks like for when you have a reactive strategy. So everyone’s really excited with this corner of department. And your touch points include sales, marketing, engineering, products, events, HR and culture, business development. Everyone wants to be a part of it and get access to your expertise. So, of course, it’s easy to be pulled in multiple directions and have that take up 110% of your time, not including anything driving your department forward.

So the problem is you shine in writing code and writing content, it doesn’t work. It’s really distracting. So, looking out, what is your company? Is it your job evangelism, advocacy, community, clown juggling? Very scary. I wouldn’t recommend it. Phil Lege… How do they pronounce your name? Lege? Like Lege? I don’t know. I’m kinda…

Phil: Like Legeta.

Jessica: Oh, I knew the real one. I was just making fun one. You wrote a great post, “Helping You Start Dissect What You Might Be Looking For Within Your Company and Developer Relations.” This is a great resource to get started to think about your strategies and start thinking about how you might want to measure success in your department. However, since we’re still trying to define this as industry, this will vary per company. What Phil defines in his blog post as evangelism might not be the same evangelism for your company, or advocacy, etc., etc., community engineer, all the different titles we have out there.

So what if your company wants it all? Fortunately, there’s a lovely graph on Phil’s blog post, and you can click which ones which you’d like to do. I had a lot of fun kind of playing with different things of what I thought was evangelism and what the graph said or advocacy. And then I clicked all of them, and I said, “What would happen?” There’s too much. You can’t do all of it. So, Phil, I’ve left a poor request for you to change this and make a fun Easter egg for all the different checkmarks. Yeah.

Dealing with budget realities

So budget cuts are real. Without a strategy in place, executives will begin to question, “What in the world is DevRel doing?” Ultimately, you can’t do it all, and unless you have a massive team and that’s your strategy, you’ve got two people. So how do you balance this? And if you tend to do the side of the gate, your department really has not a good chance of being around 6 to 12 months.

So what do proactive strategies look like? Proactive, by definition, is creating or controlling a situation by causing something to happen rather than responding to it after it has happened. You must define what DevRel means for your company. So what is DevRel to you? Dropship evangelism? Code advocate? Community champion? All the above? I have decided to reverse that a little bit after Matt’s talk just to keep you guys on your toes.

These are all important things to consider when forming your team strategy or reposition yourself. So I said “dropship evangelism.” Raise of hands, does anybody know what that means? One, two, three, five. Okay. Six. Great. So what that means, this is a term, I think, is coined from a fellow community member, and it’s an approach where you’re sending people around the world for hackathons, conferences, meet-ups to speak and expose your product, but not necessarily in a focused way.

So we see this more around the new teams. Dropship evangelism is something assigned. It’s like a new team, one that may not know where to focus yet, trying to be the new SendGrid or Twilio where you saw literally everybody there at those events in 2011. Many evangelism programs are still trying to prove themselves, and it’s really hard to have six to eight touch points with that same person with a dropship way of running that program.

This only works when you have a big team that allows one person to focus on travel and follow-up. You need different functions of engagement, multiple touch points, email, blog post email with a link, and that will help you to be successful. So evangelism is a triangle, in words, in code, and in person. You need all these types of connections with people in multiple ways and multiple times. Try to establish these things as part of your engineering culture as early as you can. This will help you scale to the point where you can head higher educated and dedicated DevRel engineers, hopefully educated as well, to focus on community by driving forward a lot of self-serve revenue.

The three Cs

Three Cs. Raise of hand, who’s heard of three Cs? I should see more than five hands. All right. Five… I’ll take it. Okay. So community code content. In 2014, this was a term coined by Brandon West in his blog post discussing developer relations. Interestingly enough, we’ve seen this around multiple places coming up as 5 Cs, 12 Cs, 4 Cs, all the Cs. And this is okay, but I think if you want to keep focus, the magic number is three. They say the third time’s the charm for a reason.

What I thought was interesting in this blog post was this little tidbit, “If you don’t have a way to reach your developers, your developer relations program isn’t worth much.” Kind of harsh, but what I think we’re looking at this is you need to have a strategy for your code content community and how you deliver it. So create the code and content, and the community will come. Field of dreams? Anyone? All right. That being said, your program will be most successful if you have a plan in place to create the code, and share with the community, and write around it.

This will give you more conversation in person, respect in the community, and, of course, giving back many times over before you ask once. I personally have a rule. I like to give back 10 times before asking once of anything from anyone. So it’s the repetition, these multiple touch points in code content community that gets developers to really understand your product and to use it.

So, for our proactive approach, we wanna define team quarterly objectives and deliverables, define individual or contributor objectives and deliverables, all the deliverables. We want to have a retrospective and look at this metric scene and iterate on those approaches. Retrospectives. We’re really good at this in engineering and product and sales. We need to be better about it in DevRel. It’s the same thing looking at those objectives and clear achievements and strategies and looking at how to iterate that and adapt.

So iteration and adaptation. Iterating’s really an important part here, but industry is not gonna stay the same, and it’s gonna continue changing whether that means for your company, your company’s strategies, or how your API is seen in that space. You might have a competitor that comes on board, and you have to completely change how you’re positioning yourself. So we are failing each other and our companies without a proactive approach.

So let’s strategise your approach. Where do we start? Strategy, by definition, a plan of action or policy designed to achieve a major or overall aim. The DevRel Bill of Rights, which I didn’t know was the talk right after mine when I heard this. I needed Anil Dasd to find the DevRel Bill of Rights early this year, which, again, great place to start. Highly recommend reading the article if you haven’t. There’s two points that really stood out to me specifically, and that’s a clear set of business goals and a well-defined place in the organisation.

Without these two, you can’t really move forward with anything on your proactive or reactive strategies if in 6 to 12 months your executive team doesn’t know what’s going on or you don’t have any money. So you wanna get buy-in or support from an executive. I don’t mean, “Hey, here’s a budget. Let’s check in with you in 6 to 12 months and let me know how it went,” but I mean a person that’s really aligned with what you and your team’s doing. What are your quarterly objectives, how are you delivering on those, and what’s next in the pipeline? They want to be with you 110%.

So let’s say that a person is a CEO or CTO. Talking with a few people in the community, for six months, the developer advocacy program reported to the CTO. They saw value and follow but have other primary concerns. We see a lot of DevRel programs possibly reporting to the CTO because we don’t know anything better. But, however, that sea level person doesn’t really have time to manage your team and to help you and be an advocate for you on the sea level behalf, because they’re running an entire other department and team, they’re in charge of the technical portion of the entire company.

The CEO is in charge of the whole company. You could have an amazing CTO. I’m not saying you don’t, but it’s definitely the exception. So, due to lack of realisation of hierarchy of needs, we weren’t able to address the chief concerns as a way to community management. Ultimately, that team was eliminated, unfortunately. So metrics versus impact. We talked about metrics. What does that mean? I wanna be able to measure my team. I wanna say like, “This is what we did. Because we did this, you know, we have as well see revenue increase by 100%,” which would be amazing but…

The parts metrics miss

Metrics don’t always tell the story of impact, and impact is not necessarily the function of time or effort. So, taco plus money in an envelope equals happy. There was an email hack that would send out an email with a budget and subject line receives the best…and got the best value from a Taco Bell menu. It was a massive success. Does anybody know Kunal Batra? Yeah? Five? Five’s my number here, apparently.

So Kunal went to a tech crunch disrupt and did this hack where you could email Taco Bell at and say like, “I’ve got $3.33, and I’m a broke college student. How can I maximise my bang for my buck?” And it would send you back an email and say, “Hey, you can get nachos and all these other things, and this is the most calories for you, so you will be sustained until tomorrow.” So it’s kind of a funny story.

He really, you know, went to a hackathon. He was just having fun over the weekend. But because it had such a big impact, he had to make sure that his team was ready to…and ready to prepare for that. So our metrics need to be able to account for those kind of spikes, and our strategy needs to be fluid enough to chase after those impactful things sometimes.

We must be militant in our strategies in order to succeed. British general Wellington used to say of Napoleon that his presence in the field made the difference of 40,000 men, or women, maybe 80,000 women. Napoleon was widely regarded as a military genius and one of the finest commanders in history. He fought 60 battles, and they only lost 8, mostly at the end, which is pretty impressive. Even though the French ultimately lost the war, historians widely regard the revolution as one the most important events in human history because of all the precedents it set.

Napoleon said, “One must change one’s tactics every 10 years if one wishes to maintain superiority.” Napoleon was fierce about strategy and taxes, creating patterns that the military teams still use to this day. This made for a nearly unstoppable force for quite some time. So, in short, Napoleon would have killed in DevRel, lining up these proactive strategies and tactics are exactly what we need to be doing to be successful within our industry.

You wanna be able to… Taking calculated risks in DevRel can be strategic. So, if you’ve got an idea and you’re like, “Well, I’ve got this crazy one. What should we do? Should we try it out?” I mean, that’s probably…  We are in this industry to try things new. We’re doing things in a different way, so you should actually use that as a calculated risk.

Napoleonic thinking

Let’s look at some kind of tech Napoleon strategies. Obviously, there’s not everybody on here. It’s just a few examples, but I think it’s important to recognise. Early Twilio and SendGrid hackathon process. I mean, I feel like every hackathon I went to between 2011 and 2014 everybody had a SendGrid T-shirt or a Twilio jacket, which I’m still waiting on mine, by the way, and they were everywhere. Like, I swear they were multiplying.

SendGrid had this accelerated program and supported… They were at every different techstar accelerator and helping them with email or any kind of tech support. Clarify champions, the Github student packet, Algolia donations instead of swag, shameless plug, and glitch pioneering, a different way of collaborative coding. These are some examples of when DevRel teams are being proactive, trying something new, and pioneering into a space that succeeded. These are strategic calculated risks for these companies that end up working for them.

Back to the French military. So the French Army recognises three principles to be applied to operation of land and forces of the tactical level. Freedom of action. The ability of a commander to use his means at any time and to act despite the presence of the enemy for the various constraints imposed by both environment and circumstances in order to control upcoming action and seize opportunities. For developer relations, we have the freedom and the unique opportunity to create our own actions for our team around strategy and our own way of success. How cool is that?

Second one, unity of effort. This is known as the convergence in space and time of actions and affects the different operational functions. Unity of effort distinguishes itself from the concentration of forces through the need to combine actions and optimise efforts in order to increase the effectiveness of the chosen objective. This principle also includes the psychological effects of a surprise and troop morale in addition to a more conventional principle of concentration of forces.

For DevRel, we have to have unity in our team. We have to supply the support for each other’s actions, support from other departments, and ultimately unify our efforts in the industry as a whole. Economy of means. Proper distribution and use of assets in order to obtain the best ratio of capabilities versus effects in order to achieve the assigned goal. The instruments for this principle are modularity, the task organisation of forces and support.

For DevRel, in order to be successful, well, frankly, we need money. We need a budget, and we need financial support, and that means from other departments. See executive support earlier. So, wow, lots of war strategy, Jessica. TLDR, step one, proactive approach. Step two, do those. Step three, profit, and we get to keep our jobs.

Summary, we need multiple customer touch points for success within our product. We need buy-in from at least one executive, a clearly defined strategy, iteration and adaptation, and surrounding yourself with SMTP, smart, motivated, talented persons. So come hang out with me at karaoke later. This was us in Tokyo. We have a lot of time for fun, and thank you for your time.


Leave a comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.