Proving Developer Relations
Recently, Braintree laid off or reassigned its entire Developer Advocacy team, and discontinued its rather famous BattleHack hackathon. A spokesperson had this to say:
Developer advocacy has become an integral part of the PayPal and Braintree businesses, and is at the core of everything that we do. As such, having a separate team focused on developer advocacy is no longer necessary.”
While I do not want to speculate in regards to the situation with Braintree, I think it highlights a larger point of proving the value of Developer Relations within a company. Now, ideally, we’d like to think that “giving back to the community” and having “developers that love your product” would in itself be enough of a justification – but the reality is that just like any department within a business – Developer Relations needs to demonstrate the value it brings.
The challenge here is that many developer relations programs are run either by marketing teams that struggle to grasp the developer community, or by developers that struggle to grasp marketing (I fall into this group). And as a developer, the metrics I’ve always used to justify my success really aren’t the same ones marketing, execs, or most businesses are looking for.
The reason for this, imho, is rather simple. They live in a different world. As a developer we could focus on writing code – and it was about the amount of code we wrote, hitting projects on preset timelines, etc. But for them, it’s not just about completing a project – but making sure that project brings value and ultimately makes money for the company.
That means they look at things differently, and many struggle to understand the developer community – so they rely on the same metrics they judge every other department by (well nearly every department).
In other words, to prove the success of our developer relations programs we need to be able to demonstrate the value we bring to the company.
Define Measurable Metrics that Align to Company Goals
Before we can prove out the success of our program we need to first understand what the expectations are. But one of the hard lessons learned is, very seldom are they what we’re told. The truth is, for most companies the idea of a Developer Relations program is new – its a buzzword that they know they need, but they don’t really understand it. As such, even at the highest levels you tend to find disagreements or different priorities for the focus of Developer Relations.
To build a successful program you need to get past the “superficial” metrics to understand what the ACTUAL business objectives are. Then, and only then can you put together meaningful metrics that demonstrate not just the success of your program – but specifically how your program is contributing to those overarching business metrics.
Keep in mind, metrics without direct ties to business objectives are nothing more than vanity metrics, or metrics that can be used to support your key performance indicators (KPIs) while also inducing “ooohs and ahhhs” – but by themselves are meaningless to the company.
After you define the KPIs that will be reported to your managers (and hopefully all the way to the executives) you’ll want to setup a dashboard or other system in which to be able to track (and share) them. If you don’t want the complexity of a system like SalesForce, I highly recommend SimpleKPI as a simple way to store and track these metrics.
However, tracking your KPIs is not enough. I honestly cannot recall a single meeting I’ve had with our execs where I haven’t been asked to dive into more detail.
With our forum activity, there was immediately a skeptical – “but are the questions getting answered?” This is an important question, because without a strong response rate, it really doesn’t matter the number of questions being asked.
Thankfully, I had that number as well, and could not only tell them what the current response rate was, but show them a trend to show them it also had gone up.
These other numbers are key to proving your KPIs and successes. It also demonstrates that your program is data driven, meaning you track everything and ensure a return on everything. Along with providing you valuable information in which to base your decisions, demonstrate your growth, support your KPIs, and generate “ooohs and ahhhs” it also instills confidence in your program from those most skeptical (because let’s face it, that’s their job).
Put a $ Value on Metrics
This was one of the hardest transitions for me. Metrics by themselves are worthless. It’s our job to demonstrate worth to our stakeholders and our execs.
For example, with forums we can highlight the reduced support costs of the company. Or in other words, what would it cost us to have someone answering those questions in the forum? If we say we have 100 forum posts, and each forum post would cost the company $15 to answer, we can show a demonstrable value of $1500 in forum posts.
We can then do the same with content. If the developers we interact are writing blog posts, and say they write 10 blog posts, at an estimated cost of $200/ea to outsource, that’s again a $2,000 value.
Some metrics are harder than others to put a dollar value to, but the overall idea is to have enough data to show the monetary value of the program, and that the value the program brings is MORE than the cost of the program (hard to do in your first year, but hopefully your stakeholders understand that and are investing in the program long term).
By being able to demonstrate a strong ROI, you are also providing your stakeholders and execs with justification for expanding the program. After all, the company is actually SAVING money by investing in your program.
Work with Marketing
This was another hard lesson learned – especially if your program lives outside of marketing. Often times marketing does not understand the developer community, and can struggle with trying to force traditional marketing towards developers.
To be honest – I’m super fortunate in that my marketing team is AWESOME and understands the community is different. But if that’s not the case, you need to find ways to work with marketing and to build a strong, solid relationship.
As a developer, here’s something I’ve learned. A lot of the stuff marketing does – they actually have really good reasons for. And they’re really, really nice people (actually they tend to be nicer than we are…). But they’re also a lot more focused on the emotional aspects – as such logic speak doesn’t really work (and sometimes comes off as insensitive). In other words, before trying to shove the logic driven developer ecosystem down marketings throats – let them get to know you and then work with them so that they can better understand the objective of your program, the metrics you’re aiming for, and then take time to listen to advice and find ways they can help (because they will have more resources than you do).
Btw, those metrics – marketing respects those numbers tremendously because they see the business value, and if you hit your metrics *usually* they’ll be completely onboard. Just keep in mind that brand is very important to marketing, and expect push back when you try to deviate from it (even if it makes sense in the developer community).
Work with Sales
Ok, once again, I have the best sales team in the world. Literally – I even ask my sales guys hang out at the booth at our conferences!!! But that’s because they want to be part of our developer community, and understand that (being an enterprise company) these aren’t the people to be selling to. So they come to better understand devs, learn, and have fun (HOW AWESOME IS THAT!).
But honestly, not every company has such awesome sales people. And developers HATE the sell… usually avoiding sales people like the plague (sorry sales, just being honest here). The problem is, that means in Developer Relations we try to shield our developers from sales – and in doing so often alienate ourselves from our sales teams.
Here’s the thing – sales is one of the most important, and most powerful departments within the organization. Without sales – we wouldn’t be getting a paycheck. They make everything happen.
Plus, they have a lot of insight into the struggles that their customers are having – they understand the downfalls and where they need help. And where they need help, the company focuses on.
If you haven’t already guessed where I’m going, sales and marketing are two of your most powerful allies at your company. Or if you choose to isolate your department – two of your biggest adversaries.
By working with sales, and finding ways to help them meet their goals (without sales becoming your goal) you are in essence demonstrating your importance to the company. That means not only can you demonstrate your value via the $$$ driven metrics you provide, but you will have sales and marketing advocating for you.
Not to mention, if you have Solutions Consultants or Sales Engineers, often times they have to create content for their customers or to close their sales. They don’t like creating this content every single time – and would love for the content they create to be freely available to all of their customers’ developers – such as making it available on your developer site (yeah – these guys are seriously awesome).
Be Present, Be Known by the Execs
Let’s face it, Executives are busy people. They don’t have a lot of free time, and trying to meet with more than one of them at a time is a logistical nightmare!!! But they are also the gatekeepers – and if you’re out of sight – you’re out of mind. Not because they don’t care, but because they have 15 million things happening at once.
As such you need to find a way to be in front of your executives, even if you have to force your way there. It’s not always easy, but again you have to find a way to be in contact with them – and keep them interested (that also means being prepared and not wasting their time, which can cause a lot of damage).
The good news is they WANT to be involved, and they WANT to know what’s going on… and they WANT to tell you what their departments need. This means the easiest way to get involved with the execs is just to schedule a meeting with them to ask them “what are your expectations, or “how can Developer Relations better serve your department?”
Literally, towards the end of every year as part of our next year’s planning I schedule 1:1 meetings with each of our execs where I ask them just three simple questions:
- What did Developer Relations do right this year?
- Where did we “drop the ball” this year?
- If you could have anything you wanted from DevRel next year, what would it be?
That’s it – but the responses are truly impactful. For some they thought we won the gold medal, for others they wanted to see improvement – but the first year I did this the answer that was most shocking (and important): “I don’t really know what you guys do.”
That answer right there is a HUGE red flag, which is why it’s so important to be in front of them and keep them in the loop. Because my guess is if you ask a lot of execs at a lot of companies, you’ll get the same response. And if they don’t know what value you bring to the table, it’s very easy to remove you from the table (not because they’re mean, but because that’s literally their job).
We immediately fixed this by getting into our all hands meetings (presenting on what we’ve done, and what we’re doing not just to the execs, but the entire company), setting up weekly updates that our execs can attend (whether or not they do, they have have access to the decks from the meetings and our stats dashboards), and getting into quarterly exec meetings to give a more executive focused report.
The change meant going from “we don’t know what you do” to “great job” and “this is awesome, my team should be utilizing this more.”
Just like your execs, it’s pretty likely that even your coworkers really aren’t sure what you do. Even friends describe me as a “professional fratboy,” not understanding what it is I actually do. At my last job, working as an evangelist I even had one coworker ask, “How does going out for drinks with friends help the company?!” (note, I was going to a meetup where I was also presenting)
This is because they don’t see the programs we’re putting in place, or understand why we’re spending $$$ on meetups. It’s easy to take these reactions with resentment, or dismiss them as they don’t understand developer relations – but that’s exactly the problem.
If someone doesn’t understand, take time to educate them – remember you have $$$ driven metrics! And by working with sales, you should have tangible stories about how you’ve impacted deals as well!
To share another story, after one of my coworkers asked me about the value of meetups, we sat down and ran through the reasons, the metrics, and some customer stories. My coworker who had been skeptical about meetups is now one of our biggest advocates for them!
“If you can’t explain it simply you don’t understand it well enough”
– Albert Einstein
On a slight tangent, if you find that you’re struggling to define what your program does, or how it impacts the company outside of complex or subjective examples – there’s a really strong chance that while you’ve internalized the value of what you’re doing, you don’t quite consciously understand it yet. If you find yourself struggling with the above, make sure you’re really taking a step back into the metrics and how each action relates to helping drive the company’s objectives.
As important as 1:1 conversations are, it’s just as important to get in front of your company to highlight these successes and share what you do. After our last company-wide presentation, multiple departments came up asking how they could work more closely with us. Not only did we show the company our value, but we actually reduced our own workload by finding ways to work with departments that were already tackling similar problems.
Just like when you get on stage to tell developers how awesome your company is – where afterwards they cheer and tweet – you should be doing the same thing with your company. You want your company championing your cause.
And with $$$ driven metrics that are directly correlated to company goals, the support of sales and marketing, the support of your execs, and the support of your company – you will succeed.
Because just like a company needs thousands of developers onboard to have a strong, successful developer community – the company also needs strong support internally for developer relations – otherwise its success will be short-lived (remember, no matter how much support you have now, people leave – and that means you need to be able to prove that support to whoever comes in, especially if they don’t see the value in developer relations).
Metrics Cat: http://www.lordsevein.com/gettin-back-at-it/catgoalswatchbirdwb/
Track Everything Cat: http://www.drodd.com/funny-attachments/funny-cats/
$ Value Metrics Cat: https://blingee.com/blingee/view/112645395-money-cat-
Marketing Cat: https://img.buzzfeed.com/buzzfeed-static/static/2015-02/2/17/enhanced/webdr11/anigif_enhanced-19314-1422917908-24.gif
Sales Cat: http://infinitetoventure.com/page/3/?archives-list=1
Exec Cat: http://thatspurrfect.blogspot.com/2015/06/cat-appointed-executive-of-company.html
Success Cat: http://ecocatlady.blogspot.com/2013_04_01_archive.html
Ending Cat: http://www.drodd.com/funny-attachments/funny-cats/
A special thank you to Caleb Thompson for proofreading prior to publication, and also for pointing out the post needed cat pictures (which as you could see, have been happily added).