Developer Relations Vs Marketing

On the eve of our annual Developer Relations Summit at Progress, I am putting together some of the final slides and agenda items and reflecting on what exactly Developer Relations means. Developer Relations is one of those disciplines where we constantly look at the role and ask ourselves if we’ve defined it correctly, if we’re doing it right and if we’re measuring the right things.

All of that seems odd considering that one doesn’t ask what an engineer does. Or what a sales person does. Those things are fairly well defined and easy to measure; either you shipped a product or you sold said product. It’s because of this modern lean manufacturing need to categorize things in ways that can be measured that I’ve often heard Developer Relations likened to Marketing or Technical Marketing. Sometimes you will find the words “Developer Relations” or “Developer Evangelism” in the job description for a Marketing Manager.

To be perfectly clear, Developer Relations is not Marketing.

Attractional Vs Relational

When we think about Marketing, we can think about it as an attractional model of connection with customers. Marketing by it’s function says “Look at me! Look at me!”. You can hardly get away from it. It’s on your favorite web pages. It’s before the YouTube video you want to watch. It’s plastered all over highways and in between every 3 songs on Pandora.

Marketing is often done in a way that is intrusive and overpowering. There is a good reason for that. Many brilliant marketing minds have provided good evidence to show that you can imprint and idea into someone’s mind and get them to take action simply by saying it to them over and over again. Kind of like Inception, but with 100% less Leonardo.

In 1885, Thomas Smith wrote the following about advertising.

The first time people look at any given ad, they don’t even see it.

The second time, they don’t notice it.

The third time, they are aware that it is there.

The fourth time, they have a fleeting sense that they’ve seen it somewhere before. The fifth time, they actually read the ad.

The sixth time they thumb their nose at it.

The seventh time, they start to get a little irritated with it.

The eighth time, they start to think, “Here’s that confounded ad again.”

The ninth time, they start to wonder if they’re missing out on something.

The tenth time, they ask their friends and neighbors if they’ve tried it.

The eleventh time, they wonder how the company is paying for all these ads.

The twelfth time, they start to think that it must be a good product.

The thirteenth time, they start to feel the product has value.

The fourteenth time, they start to remember wanting a product exactly like this for a long time. The fifteenth time, they start to yearn for it because they can’t afford to buy it.

The sixteenth time, they accept the fact that they will buy it sometime in the future.

The seventeenth time, they make a note to buy the product.

The eighteenth time, they curse their poverty for not allowing them to buy this terrific product.

The nineteenth time, they count their money very carefully.

The twentieth time prospects see the ad, they buy what is offering.

This is called Effective Frequency. This is the cornerstone of modern Marketing. That means that everyone selling a product knows they have to get their message in front of you 20 times before you will buy. This is why the average consumer sees between 4,000 and 10,000 ads every day. That’s Marketing saying, “Look at me! Look at me!” That’s a DDoS attack on your head!

Developer Relations flips this model on it’s head and says “Let’s talk about you”. Developer Relations acknowledges that there is a human being on the other end of any commercial exchange, and that human being has feelings and struggles. They get sad. They have good days and bad days. Everyone is fighting a battle that we cannot possibly comprehend. It’s to that end that Developer Relations seeks to help the company sell it’s products by going into the community where the customers are and sharing their burdens.

Here is another way to think about it. Imagine that someone is building a house. As they build the house, multiple people are walking by on the sidewalk and yelling things to them. “Buy a nail gun! You’ll go so much faster!” “Get a new hammer!” “Look at this gorgeous tape measure!” This is Marketing.

Developer Relations is the person on the lot next to you that’s also building a house. Both of you are doing the same work, but the Developer Relations person is using a certain set of tools because she works for the company making those tools. After a while the two of you become friends. A little while on you realize that there are some things that this person is doing that seem to work really well because of the tool that they are using. It’s at this point that you tune out all of the marketing noise and begin to make your purchasing decisions based on your friendship with the individual next to you and your respect for the work that they do.

This is the essence of Developer Relations.

Personal vs Impersonal

Marketing is, by definition, impersonal. Organizations and Corporations don’t have souls. They are entities that do not feel despite their best efforts to do so and the feel good commercials that make them seem like they might. That’s not to say that the individuals that work there don’t feel, but rather that the collective hive, that thing which sells and needs to grow to stay alive — that thing does not feel. It cannot feel because you are too far removed from the individuals behind it.

We do not form relationships with groups of thousands. We form relationships with one person at a time.

This was echoed just recently in some investigative journalism that was done on Facebook. They reported that people on Facebook are more likely to be left depressed by the interactions that they have. Why is that? Aren’t all those people their “Friends”? Of course not. These are simply people that you know of. Meaningful response only occurs when there is deep 1:1 interaction. We can have this deep interaction with multiple people, but it has to occur or we are left feeling alone. Shallow relationships drain us. Deep ones are the fuel by which we keep moving day after day.

Marketing on it’s own will leave consumers without any meaningful interactions with a company, which means it will ultimate drain consumers. Without a connection, there is no “stickiness”. In other words, in order to keep this consumer loyal to your brand, you must constantly churn out a string of products and chant about those items day in and day out.

This model of interaction is classic and proven, but also quite expensive.

The market — any market — is saturated with competitors doing the exact same thing you are with a highly comparable product and a team of Marketers who are just as aware of effective frequency as you are. This is where Developer Relations becomes the competitive differentiator.

Developer Relations forms meaningful relationships with consumers built on mutual respect and trust. This is possible because Developer Relations is in the field, meeting customers and experiencing their exact same pains, frustrations and needs day in and day out. This has the added benefit of providing you with first-hand knowledge of what it’s like to actually use the tool or product that you have created.

In Defense Of Marketing

Now my good Marketers out there will take serious issue with the above point and point out that theories like effective frequency (The above is considered one theory of Effective Frequency) have many different interpertations. They will also say that it is quite possible to have meaningful interactions with individuals via standard marketing mediums if it is done well.

On this notion, I entirely agree.

I am not suggesting that Marketing as a function is all bad, but rather the model that we’ve come accustomed to is.

At Progress, we attach Marketing and Developer Relations at the hip. For any product we have both a Marketing Manager and at least one Developer Advocate. It is through this relationship that we help create meaningful messaging with marketing while building meaningful relationships in the community. When you are able to get these two groups to work together successfully, the ultimate goal is to get your Effective Frequency numbers down as low as possible through the use of Developer Relations. Not only does this save a lot of money spent on Marketing; usually the largest cost center in any organization, but it should also drastically increase customer loyalty. Anyone who has run a business knows that loyal customers are how a business is built.

Merging Developer Relations With Marketing

This might lead one too ask, “Couldn’t we just combine Developer Relations and Marketing into the same role and eliminate redundancy?”

This is another urge perpetrated by those lean manufacturing principals on which modern industry is propped up, but which will ultimately leave you with only Marketing and no Developer Relations.

Marketing has discreet goals. Sometimes these are MQLs (Marketing Qualified Leads) and sometimes they are actual sales quotas. As soon as you assign a product metric to an organization, you remove their ability to form relationships with the consumer. Imagine if that Developer Advocate building the house next to you was told they had to sell 10 hammers every month. It’s going to be very hard for them to form any sort of meaningful relationships because they will always have the agenda of selling you a hammer, which completely flattens their integrity.

People are very cautious of these sorts of interactions in their lives and they avoid them. There is nothing more insulting than someone who shows interest in you so that they can sell you something. If you’ve ever been propositioned for a Multi-Level Marketing Scheme, you know exactly what I’m talking about.

Developer Relations is wholly different because it’s output is hard to discreetly measure. Modern lean manufacturing principles eschew what cannot be measured. As if a lack of measurement is an indication that the need doesn’t exist. Ignoring what can’t be measured is a fools errand with honorable intentions.

All of that said, Developer Relations most certainly should be measured, and there are different theories about how to properly do this, but that is another post for another time.