Let’s be honest, Developer Relations is all the rage, and why shouldn’t it be!? Developers have become a powerful force, and companies like Microsoft, Google, Twitter, Amazon, Twilio, EngineYard, Stripe, PayPal, Xero, Constant Contact… ok the list goes on and on. Point is we’re seeing LOTS of companies looking to create their own program and get into this community.
But for as many that are looking at getting into this amazing space, just as many are failing, or jumping in and burning out. So why aren’t more companies succeeding in this space? Let’s take a quick look at some of the deadly sins I’ve seen be committed, that ultimately lead to developers being turned off, and a company wasting LOTS of money to learn these lessons the hard way.
It’s Hard Work
First and foremost, I don’t think most companies realize how much WORK goes into developer relations. Like the whole social media buzz, I think a lot of companies believe they can just hire a developer evangelist and send him or her out into the world to work their magic. Post a few blog posts, attend a few conferences, and viola – developers will come in masses. But not so fast!
First of all, the key to developer relations is TRUST. In fact, it’s been my experience that you really see the effects of your work as late as six months after the fact… Building a successful developer relations program takes YEARS with an intense focus on not just “blogging” but becoming subject matter experts with a service developers can thrive on, and SMEs that are ALWAYS around. No developer relations program is built overnight, so you’re company has to be willing to dig in and be prepared to do some HARD work. If you’re trying to build a developer relations program working 9-5, or on minimal resources… FORGET IT.
Not Having a Unified Vision
One of the greatest challenges with developer relations is the number of departments it impacts, ranging from PR to HR to Marketing to Sales to Biz Dev to Tech Support. Unlike many departments that can operate interdependently, the developer relations program is often reaching into all of these departments. This can lead to departments wanting to sway the program to meet their specific requirements or goals, neglecting (often times without realizing it) the needs and goals of the other departments. This results in other departments placing demands and needs on the program, pulling it a completely different direction. If your program is not under a set strategy that is controlled by a specific department (even its own) there is no way to be successful as you will instead find a house divided upon itself, and a program that is no longer effectively able to operate as it becomes Sales, Marketing, Tech Support… well everything BUT developer relations.
Not Understanding Developer Relations
Developer relations is still a fairly new field, and as such it’s one that many companies still do not understand. Developer relations isn’t sales, it’s not tech support, or even traditional marketing. So often companies get stuck in trying to turn their developer relations program into “tech support specialists” or “salesmen,” but the purpose of the program is to build relationships with developers and get them excited about your product. The purpose of a developer relations program is to grow word of mouth advertisement and customer engagement throughout the developer community, not get the quick sale. Developer relations programs take time to gain momentum, and also time to become profitable. If you focus on instant ROI instead of long-term gains the program will fail. Likewise, stopping your developer relations team from engaging in their communities and doing what they do best and trying to turn them into salesman or tech support will cause them leave, bringing us to the next reason developer relations programs fail.
Taking Your Resources for Granted
Did I mention that developer relations is tough work? One of your most vital resources are your developer advocates. They are your eyes and ears on the ground, and can provide you with invaluable resources and feedback- they can help your company bridge the developer community and act as a two-way translator. However, this is a very special and rare breed, a breed that wants to mix code with public speaking, and doesn’t mind ridiculous hours and not having a life… doesn’t mind having to be “on the job” 24×7.
A lot of companies don’t understand how to take care of their developer advocates, and as the program grows instead create an atmosphere that creates more challenges for them, adding to their already stressful load. It’s important to remember why your program is successful, and to trust the feedback you receive. It’s also important to take into consideration that they are putting their reputation on the line for you, and ensure that they are getting the resources and internal support they need to do their job. It’s also important to make sure the home environment is as friendly for your advocates as possible as they are constantly on the road and prone to burn out (most advocates last less than a year).
When trying to build a successful developer relations program that takes years to achieve, losing these critical, and hard to replace resources is extremely damaging, and can cause anything from a major setback to even causing the program to fail completely.
Valuing Leads over Relationships
So I stole this one from another blog, but it is so true I couldn’t omit it. Traditional marketing tells us to get leads, and the more leads we get the more sales we make. However, developer relations is called just that for a reason – it’s about building relationships… There’s a reason we don’t call it “developer marketing.”
Developers are an extremely vocal force, and a truly powerful consumer base. It’s not a matter of collecting leads, but building your reputation in this community, which again takes time. The second you emphasize leads over relationships is the second you start sinking your developer relations ship. Treat developers like people, build friendships, and create allies, otherwise when the competition attacks you’ll find yourself standing alone. Or worse, you’ll find the very developers you tried to “sell to” standing with them.
Inability to Segment Markets
Chances are your company is REALLY good at marketing to your customers, but unless your customers are developers this creates a huge challenge. Developers think differently and want different things. Approaching developers in the same way you would say small businesses will only result in confusion and leave them thinking that you’re out of touch. In fact, while you’re at it, forget the marketing all together- focus on relationships and sharing your product, not marketing… it will get you farther. Value developers for the unique and valuable skill sets, recognize and invest in what’s important to them, not what’s important to you or your different target markets. After all, you wouldn’t go to your Spanish friend and force him to speak French, so why do that with developers?
Marketing teams try to Market
Ok, in case you missed it in my first blog post, or chose not to read the above section… One of your most dangerous teams in developer relations is your marketing team. The catch is that’s usually the team responsible for developer relations, making things pretty interesting.
I’ve talked with some people in marketing who “just get it,” and they do a great job at developer communications, but the problem is that most marketing people think “they get it” when in reality they know about as much about this community as I do cars (or nothing at all other than it has a steering wheel and gets me places). This means they jump to the stereotypes – hey let’s get cheesy emotionless robots (disclaimer, I like Rosie as a cartoon), circuit boards, or anything else we can get from the 1950s (ok 1950s might be cool, but the 1990s aren’t so much). Instead of seeing cool, modern, and slick designs developers get taunted with unattractive, unappealing, and at times insulting displays of what we’re supposed to be like. And that’s a turn off.
So to summarize my last post, if you’re not a developer- don’t try to be. If you don’t know their language, don’t make it up as you go. Take some time and learn it before you try to speak it. And please, please, please… just stop “marketing.” It doesn’t work.
A Lack of Creativity
Do me a favor, sit at your computer… good. Now open TextEdit or Notepad and just start typing code for 12 hours… tired? Mentally exhausted? Welcome to the life of a developer. But what did we do with that code- well we created! We built an application using techniques that were challenging and concepts that others may have never thought of. We pushed the limits of our capabilities, both our own and technology. We did something great! And now we’re ready for a creativity recharge!
But most companies lack creativity, in fact I joke that larger companies have “uncreative departments.” Companies are hesitant to try anything they haven’t before, to step outside of social norms, to take a cat and mash it with an octopus and then put a spacesuit on it. An Octocat!? Whattttttt? But these are the types of things developers LOVE (just check out the Octodex). If you can’t bring fun and creativity to the table, you’re going to be boring. Plain and simple. Find something that says “this is who we are,” and encompasses your company’s values, and your passion for technology/ life in general.
Plus, you can have a ton of fun with this and get even more exposure!
Being too Professional/ Not Professional Enough
So this is another catch 22, but at conferences you see the companies that are wayyyy too professional (depending on your environment of course) and are dressed to the 9, won’t ever leave the booth, and engage in only job related conversations… and then you have the guys who are shamelessly throwing out crude jokes and hitting on attendees. Point is, you probably shouldn’t be doing either – you should be relaxed. Again it’s about developing PERSONAL relationships, not leads. Get to know attendees, have fun, join in at happy hours/ after parties (but PUH-LEASE do not talk about your business unless we bring it up).
This is another area where your developer advocates can be vital, as this is their community, the very community they’ve thrived in. Trust their judgement on how to handle events, and let them dictate what you should be doing/ saying… even if it doesn’t make sense to you.
Not Being Serious about Your Program
This goes back to the hard work, but if you create a developer relations program you are opening a can of worms. You’re engaging the developer community on a deeper, more intimate level. You’re giving them permission to question you to your face, to criticize your product, to bash it… but now they expect you to do something about it. If you’re not willing to put the work in, if you’re not willing to listen to their problems and fix them, if you’re not willing to be creative, if you’re not willing to work on building and maintaining relationships, then you’re better off saving the money for something else.
After all, the only thing worse than not having a developer relations program, is having a developer relations program that’s out of touch and destroys what little trust and credibility you may already have with this community.
